[03:00] <luke-jr> bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.
[03:00] <luke-jr> How can I resolve this?
[03:01] <jelmer> luke-jr: well, you can't really resolve that but you can force bzr to merge anyway by using "bzr merge -r0..-1"
[03:01] <luke-jr> jelmer: will that copy the metadata?
[03:01] <luke-jr> jelmer: my target branch is empty
[03:01] <luke-jr> a simple Svn repo with a single commit creating trunk, branches, and tags
[03:02] <jelmer> luke-jr: if your target branch is empty, why would you merge rather than pull?
[03:02] <luke-jr> pull doesn't work either
[03:02] <luke-jr> bzr: ERROR: These branches have diverged. Use the merge command to reconcile them.
[03:03] <jelmer> luke-jr: what do you have locally?
[03:04] <luke-jr> everything ☺
[03:04] <jelmer> luke-jr: I mean, what repository format?
[03:04] <luke-jr> origin is CVS and Subversion
[03:04] <luke-jr> I uses the cvsps thing to turn CVS into Bazaar
[03:04] <luke-jr> now I need to put the Subversion revisions on top of that
[03:05] <jelmer> luke-jr: that's not likely to going to work as the file ids will be different
[03:05] <luke-jr> I can delete the Subversion repository once complete. I think.
[03:05] <jelmer> so merging will result in a lot of conflicts as bzr thinks there are two different files with the same name
[03:05] <luke-jr> well, that's why I'm going from Bazaar to Subversion first
[03:05] <luke-jr> so Bazaar can set up its revprops
[03:06] <luke-jr> and then loading the svndump should just commit the Svn repo's changes to existing files
[03:07] <jelmer> luke-jr: so, creating an empty "trunk" directory in svn is the first commit in that branch
[03:07] <jelmer> and that branch obviously doesn't share any history with the bzr branch you're trying to merge
[03:07] <luke-jr> the only commit in the new dummy Subversion repository
[03:07] <luke-jr> I'm trying to take the bzr branch's history to Subversion
[03:07] <jelmer> luke-jr: what you *can* do is push the entire branch from bazaar into svn
[03:07] <luke-jr> exactly
[03:08] <jelmer> luke-jr: but to be able to do that /trunk shouldn't exist yet
[03:08] <luke-jr> what is it going to push into? O.
[03:08] <jelmer> luke-jr: and you can then run 'bzr svn-push <repo-url>/trunk' from the bzr branch
[03:08] <jelmer> that will create the svn branch and push all contents
[03:09] <luke-jr> will it create branches and tags too?
[03:09] <luke-jr> the dirs
[03:09] <jelmer> luke-jr: it will create those if it needs them but they can exist
[03:13] <luke-jr> jelmer: btw, will I have trouble when I need to merge upstream CVS commits?
[03:14] <jelmer> luke-jr: no, you'll be able to keep merging from the branch imported with cvsps
[03:20] <luke-jr> jelmer: is it possible to backdate commits?
[03:20] <luke-jr> (I'm turning patches into branches)
[03:26] <jelmer> luke-jr: It's theoretically possible, but I don't think bzr allows anything like that on the command-line
[03:26] <jelmer> s/theoretically/technically/
[03:26] <luke-jr> any other metadata I might want to manipulate?
[03:28] <jelmer> --author perhaps
[03:29] <luke-jr> ok
[03:29] <luke-jr> --author plus libfaketime ;)
[03:30] <luke-jr> timestamp: Sun 194065-07-12 23:15:44 -0500
[03:30] <luke-jr> that didn't work :o
[03:32] <jelmer> whoa :-)
[03:32] <luke-jr> oh well
[03:32] <luke-jr> I'll just declare it the commit time instead of change time
[03:32] <luke-jr> :/
[03:38] <vinc456> i'm a little confused about the docs. says "* Talk to us in irc://irc.ubuntu.com/bzr"
[03:38] <vinc456> i tried to connect and it seemed to lead to here
[03:38] <luke-jr> vinc456: what's to be confused about?
[03:38] <luke-jr> this is #bzr
[03:38] <vinc456> isn't this freenode?
[03:39] <vinc456> is this the "official" channel?
[03:39] <jelmer> vinc456: irc.ubuntu.com points at freenode
[03:39] <jelmer> vinc456: yep, this is the official channel
[03:40] <vinc456> weird
[03:41] <ezyang> Hello all, I'd like to check out all of the branches of a repos that I checkout one branch of. Is there an easy way of doing this?
[03:51] <ivan> I pulled someone's trunk into my no-working-copy branch
[03:51] <ivan> bzr said a lot of things conflict because it expected files to be there
[03:51] <ivan> how do I escape from this mess? :)
[03:53] <jelmer> ivan: bzr won't create conflicts if there is no working tree
[03:54] <jelmer> ivan: can you expand a bit as to what's happening?
[03:54] <ivan> http://rafb.net/p/mGvDyg47.html
[03:54] <ivan> I think what might be the problem is that I manually removed the working trees
[03:54] <jelmer> ah, not using 'bzr remove-tree' ?
[03:54] <ivan> I touched a file somewhere to convince bzr not to create working copies any more
[03:55] <ivan> but perhaps that was not enough to switch to no-trees
[03:55] <ivan> jelmer: yeah :(
[03:55] <jelmer> ivan: you can just remove those files manually again (everything except .bzr) and then run 'bzr remove-tree'
[03:58] <luke-jr> I can't find version 1 of a patch
[03:58] <luke-jr> can I commit version 2 and edit the history later? ;)
[04:02] <ivan> jelmer: thanks, my branches are back to normal
[04:02] <ivan> took me a few minutes to figure out that I should be doing merge ../trunk instead of merge trunk, though
[04:07] <Peng_> bzrtools's clean-tree command makes it easier to delete all of hte unnecessary files.
[04:07] <Peng_> (See the help, though.)
[04:11] <ivan> i'm trying to figure out how to recreate the tree so that I can remove-tree
[04:11] <ivan> I have uncommitted changes involving all the files being gone
[04:11] <ivan> this is just a problem in the branch, not in the checkouts
[04:12] <jelmer> ivan: try 'bzr revert'
[04:12] <ivan> jelmer: thanks again, life is good now
[06:31] <meoblast001> how do you delete a bazaar branch
[06:35] <Peng_> meoblast001: rm -rf
[06:36] <backz> hi
[06:36] <Peng_> meoblast001: If you're using a shared repo, it's not trivial to remove the now-unnecessary revisions from it. Most of us just live with the couple MB of wasted disk space.
[06:36] <Peng_> It probably wouldn't be hard to write a "gc" plugin though.
[06:37] <meoblast001> how do i remove a branch from a proejct
[06:37] <Peng_> backz: Hello
[06:37] <Peng_> meoblast001: Eh? On Launchpad?
[06:37] <backz> I'm using bzr for a private project, I need to share this repo with team, need I pay some host service with shell in order to give write-access to this repo to all my team remotely?
[06:37] <meoblast001> Peng_: yues
[06:38] <Peng_> meoblast001: There's a little X button next to the branch's title on its web page.
[06:38] <Peng_> backz: All you really need is SFTP (or, god forbid, FTP).
[06:39] <meoblast001> https://code.launchpad.net/amethyst-mm where?
[06:39] <Peng_> meoblast001: Click on the branch.
[06:39] <meoblast001> k
[06:40] <backz> I've looking for services like github, but it's only for git. Lauchpad is only for open source apps.
[06:41] <Peng_> I don't know of any. :\
[06:42] <backz> is bzr slow to transfer data by sftp ?
[06:42] <backz> in the first edition, it was.
[06:44] <Peng_> backz: Well, it's certainly not as fast as the smart server, especially after all the recent work on improving the smart server's performance.
[06:44] <meoblast001> Peng_: i'm lost
[06:45] <meoblast001> i don't see an x https://code.launchpad.net/~tedks/amethyst-mm/devel
[06:45] <Peng_> meoblast001: You own that branch?
[06:45] <meoblast001> no
[06:46] <meoblast001> it just got randomly sorted in with my project
[06:46] <Peng_> meoblast001: Well you can't delete other peoples' stuff.
[06:46] <meoblast001> i don't know why
[06:46] <meoblast001> i don't want ot
[06:46] <meoblast001> i dont want it in my project
[06:46] <Peng_> meoblast001: It looks like it's related to your project.
[06:46] <meoblast001> oh
[06:51] <BasicOSX> The server at bugs.launchpad.net is taking too long to respond. <- just me or others have problems?
[06:53] <Peng_> Umm, if Firefox wasn't swapping, I'd check.
[06:55] <Peng_> BasicOSX: https://bugs.edge.launchpad.net/ works for me
[06:55] <Peng_> Sigh, I think I've given up on "WFM" :(
[07:43] <wgrant> backz: You can use Launchpad for proprietary projects, but you have to pay.
[14:00] <olliepetch_> hey guy's i'm just exploring the bzr code base and am trying to find where a file is distinguished between text or binary before a delta is written to repository, can anybody let me know where this code lye's? cheers
[14:05] <olliepetch_> hey guy's i'm just exploring the bzr code base and am trying to find where a file is distinguished between text or binary before a delta is written to repository, can anybody let me know where this code lye's? cheers
[14:05] <Peng_> Deltas are binary, although the current formats are all line-based.
[14:06] <Peng_> So...it doesn't.
[14:08] <LarstiQ> olliepetch_: I suppose you want to accomplish something with this information?
[14:10] <olliepetch_> yeah i want to add an extra check to see if it is a odf file, so i can open up the archive and store difference data on the content.xml file
[14:12] <LarstiQ> olliepetch_: hmm, I'd probably start by looking at the different merge types in bzrlib.merge
[14:35] <backz> hi
[14:42] <Peng_> Hi
[14:45] <yacoob> If I have a shared repo, with one branch in it, would branching it outside, and then pushing to a "new" branch in the same repo result in shared storage use?
[14:45] <yacoob> or do I need to go to the repository and do 'bzr branch old new' there?
[14:46] <james_w> it would
[14:47] <james_w> the second option only requires one branch operation though
[14:47] <LarstiQ> but the results inside the repo would be the same for options 1 and 2
[14:48] <yacoob> great, that's what I expected, but I wasn't sure :)
[14:50] <yacoob> so, how is it done under the hood? I mean, do the branches have uuids and upon new push bzr recognizes that the new one was branched from the old one? Or does it analyse the files and spots similarities?
[14:53] <LarstiQ> yacoob: every commit has it's own unique revision id. A branch is just a pointer to a revision.
[14:53] <LarstiQ> yacoob: so if you just `bzr branch old new`, all the revision objects will already be in the repo, 'new' is just an additional pointer.
[14:55] <yacoob> LarstiQ, what I'm wondering about is, if I'm pushing *some* branch X to a shared repo - will it share storage only if it has been branched from something already in the repo, or will it work as long as the files in the branches have "similar" content?
[14:56] <LarstiQ> yacoob: it will need to share revisions, files having similar content will not do it.
[14:56] <Peng_> (
[14:57] <Peng_> (Although they might in a future disk format.)
[14:57] <Peng_> Err. Did that make sense?
[14:57] <LarstiQ> yacoob: you can use `bzr missing` to see which revisions will take up additional storage space.
[14:57] <LarstiQ> well, roughly
[14:57] <LarstiQ> s/see/get an idea of/
[14:57]  * Peng_ goes to bed. Maybe.
[14:58] <yacoob> neat, thanks
[16:22] <nekohayo> let's say I want to revert a change that was made in a previously merged revision, what would be the best way to go about it?
[16:22] <nekohayo> let's say I'm at rev 119 and I want to revert what was done in rev 98.3.36
[16:23] <LarstiQ> nekohayo: you can commit the reverse diff: `bzr merge -r 98.3.36..98.3.35 .; bzr ci`
[16:24] <nekohayo> o_o and that won't mess up history or anything6
[16:26] <nekohayo> so basically, "bzr merge -r 98.3.36..98.3.35 ." and then "bzr commit". Interesting
[16:26] <LarstiQ> nekohayo: that will leave the old 98.3.36 intact.
[16:27] <LarstiQ> nekohayo: if you needed to remove that revision, you could bzr uncommit (and then a rebase invocation to keep the content of the newer revisions)
[16:27] <nekohayo> nah, I guess just reverting the actual code is enough
[16:27] <nekohayo> it's not seen as a "merge" by bzr status though
[16:28] <nekohayo> I guess it's just as if I did the diff manually and committed a new revision
[16:28]  * LarstiQ nods
[16:29] <nekohayo> about cherry picking, I'm still a bit confused. What happens to history if I cherry pick something from another branch? And more importantly, does using cherry-picking imply that once you use it, you must keep using it for all further merges from that branch?
[16:33] <nekohayo> that's basically what makes me hesitant to use it
[16:35] <LarstiQ> nekohayo: to start at the end. No, you don't need to keep using cherry-picking.
[16:35] <LarstiQ> nekohayo: the first question, nothing happens to history.
[16:35] <nekohayo> (actually it was pretty much the same question, now that I think of it ;)
[16:36] <LarstiQ> nekohayo: A cherry pick in Bazaar does not currently record any metadata, only content changes.
[16:38] <nekohayo> LarstiQ: example: I merge from "bob" who has revisions 1,2,3,4, and I cherry-pick 2-3. But then if it doesn't merge the metadata, what will happen when I do a simple "bzr merge bob" afterwards? that's what was puzzling me
[16:38] <nekohayo> won't it pull in revs 1,2,3,4 all at once?
[16:38] <nekohayo> merge*
[16:43] <LarstiQ> nekohayo: yes, but Bazaar will not conflict on the content of 2,3 already being present
[16:44] <nekohayo> oh, that's nice :) I guess it's just a social question rather than a technical one then
[16:44] <nekohayo> as in if you disagree with someone's branch or something, you have to keep cherry-picking it ;)
[16:47] <LarstiQ> nekohayo: If there is just one thing you disagree with, merging everything and applying the reverse diff works as a 'reject'.
[16:48] <LarstiQ> nekohayo: in general we tend to encourage doing orthogonal work in seperate branches
[16:51] <nekohayo> LarstiQ: ok, but that needs to be done in separate commits, afaik. Actually, I'm not in need of things like this so far, I was just doing an exercise in thought :) is there such a thing as a bazaar/dvcs etiquette in the docs?
[16:52] <LarstiQ> nekohayo: maybe, I'm not aware of it. It's a good idea though.
[16:53] <nekohayo> I think it would be a neat thing for switchers from centralized models, or even for people starting from zero into the VCS world
[16:54]  * LarstiQ nods
[17:03] <nekohayo> LarstiQ: I obviously don't have the knowledge for this, but should I file a bug about bzr's docs or something?
[17:05] <LarstiQ> nekohayo: if you can't find such a thing on the wiki or on doc.bazaar-vcs.org, go ahead
[17:05] <LarstiQ> nekohayo: or perhaps start a page on the wiki
[17:05] <LarstiQ> nekohayo: http://bazaar-vcs.org/Scenarios might come close
[17:08] <nekohayo> indeed, "Review and accept changes from others, into a project that I manage using bzr" ; however, that page doesn't exist :)
[17:10] <LarstiQ> nekohayo: create it, note down how you think it should be done, and someone will correct it if needed! ;)
[17:11] <nekohayo> that's the problem, I don't really have much of an idea how it should be done :)
[17:15] <LarstiQ> nekohayo: I have some ideas for that
[17:17] <nekohayo> hm. maybe you could start that etiquette/good management practices page and I could watch it and comment
[17:18]  * nekohayo has a weird feeling that this is also the kind of things that usually gets demonstrated in live talks
[17:18] <LarstiQ> it is
[17:19] <nekohayo> afaik there are no recordings of those talks on the website :)
[17:19] <LarstiQ> nekohayo: I've put it on my todo list, I won't be doing it for a while today
[17:20] <nekohayo> should I point specto to a particular page to watch out for?
[17:21] <LarstiQ> nekohayo: the Scenarios page
[17:21] <nekohayo> allright
[19:31] <luke-jr> I'm trying to create a branch with its first revision being a merge of another existing branch
[19:31] <luke-jr> eg, start the numbering over at 1
[19:32] <luke-jr> yet, if I do bzr init foo; cd foo; bzr merge ../bar
[19:32] <luke-jr> bzr status says I am not "up to date" and bzr update deletes all the merged files; bzr commit then creates a revision with delete for all of them
[19:32] <luke-jr> what am I doing wrong? :/
[19:38] <jkakar> luke-jr: I don't think you want to do a merge.  This is basically just a fresh branch with a bunch of new files added... ie: you explicitly don't care about the history of those files.
[19:38] <luke-jr> jkakar: I *do* want the history
[19:38] <luke-jr> just as 0.1.*
[19:39] <luke-jr> I also want to retain the ability to merge from other branches
[19:39] <jkakar> luke-jr: Hmm.  Why do you care about the revision number starting at 1?
[19:39] <luke-jr> jkakar: I'm importing ☺
[19:39] <jkakar> luke-jr: Uhm, I don't understand what that means.
[19:39] <luke-jr> and I'd prefer my trunk branch not be renumbered
[19:39] <luke-jr> I'm moving my Subversion repository
[19:39] <jkakar> Ah ha.
[19:39] <luke-jr> rev 1 is my initial import
[19:40] <luke-jr> I want to keep it the same in Bzr
[19:40] <jkakar> I'm not sure how you would do that, sorry.
[19:40] <luke-jr> sigh
[19:40] <luke-jr> if it was rev 2, it'd be easy
[19:41] <luke-jr> oh
[19:41] <luke-jr> stupid me
[19:41] <jkakar> If the SVN repository is public, I would probably just arrange Launchpad to do a vcs-import for me and let it all happen magically.  I don't think it'll do what you want withj revno's though.
[19:41] <luke-jr> svn and bzr revno are going to differ no matter how I do it
[19:41] <luke-jr> jkakar: not that simple ☺
[19:41] <luke-jr> I don't think Launchpad's VCS import is designed for branches spanning CVS and Subversion both
[19:42] <jkakar> luke-jr: Launchpad can import from CVS and Subversion.
[19:42] <luke-jr> jkakar: whilst keeping merges between the two consistent?
[19:43] <jkakar> luke-jr: You probably need to use bzr-svn if you want to do that.
[19:43] <luke-jr> that only works with Svn
[19:43] <luke-jr> not CVS
[19:43] <jkakar> Ah, I see.
[20:18] <vinc456> luke-jr: how do you type a smiley face?
[20:19] <luke-jr> I press ':'
[20:19] <luke-jr> then ')'
[20:19] <luke-jr> ☺
[20:21] <vinc456> luke-jr: hmmm, maybe your client transforms it because when i message myself i just see a colon and right parenthesis
[20:25] <NfNitLoop> yeah, his client is sending some unicode character.
[20:29] <ricardokirkner> hi. I am tracking an svn bzr using bzr-svn.. I keep getting bzr prompting me for the password, although this is supposed to be already handled. I am trying to trace the auth code, but its never being called. Maybe its something to do with that my branch starts with https:// instead of svn+https:// ?
[20:37] <luke-jr> bzr: ERROR: Prefix missing for branches/randomRange; please create it before pushing.
[20:37] <luke-jr> wtf? :/
[20:41] <bob2> bzr push --create-prefix
[20:41] <bob2> it doesn't create more than one level of directory, by default
[20:59] <ricardokirkner> hey jelmer. how are you doing?
[21:01] <ricardokirkner> I just wanted to know if some behaviour I am seeing is alright or is a bug: when I have an svn branch directly using the https:// transport, it doesn't use the svn credentials; however if I use the svn+https:// transport it does, but it says the svn+ is deprectaed and I should use the https directly
[21:02] <ricardokirkner> I would like to fix this issue (if it is a bug indeed), but I would like some guidance, as to not loose myself within the code :-)
[21:02] <LarstiQ> sounds like a bug to me
[21:03] <ricardokirkner> I guess I would have to modify the bzrlib/transport/http/<somefile>
[21:03] <ricardokirkner> to determine if the underlying repo is svn or not and in the former case, request the svn credentials
[21:03] <ricardokirkner> am I right?
[21:03] <LarstiQ> ricardokirkner: no, that doesn't sound right
[21:03] <ricardokirkner> LarstiQ, what do you suggest?
[21:04] <LarstiQ> ricardokirkner: bzr-svn does interact with the http:// url, right?
[21:04] <ricardokirkner> supposedly, yes
[21:04] <ricardokirkner> I mean, it is working alright, except for the credentials stuff
[21:05] <ricardokirkner> it is as if the http transport is being handled by another handler that is not svn aware
[21:05] <ricardokirkner> which make complete sense
[21:05] <ricardokirkner> as the http protocol might be used for bzr repos too
[21:06] <LarstiQ> transports and credentials aren't tied directly to each other
[21:06]  * LarstiQ looks at the bzr-svn code
[21:07] <LarstiQ> ricardokirkner: svn/auth.py is where I'd look
[21:07] <ricardokirkner> yes, I have already looked in there
[21:07] <ricardokirkner> the thing is, the auth.py stuff is not being called for credentials
[21:07] <ricardokirkner> I have set some breakpoints in there, but the pdb never halts on them
[21:08] <LarstiQ> ricardokirkner: but it does for https?
[21:08] <ricardokirkner> no
[21:08] <LarstiQ> how have you set breakpoints, and where?
[21:08] <ricardokirkner> what I meant before is: the svn repo handling is working alright, but the http/https credentials stuff are being handled by another handler
[21:08] <ricardokirkner> I am running "pdb /usr/bin/bzr pull"
[21:09] <ricardokirkner> when it starts I set a breakpoint on the code I want to analyze
[21:09] <ricardokirkner> e.g. auth.py
[21:09] <LarstiQ> hmm, that might work
[21:09] <ricardokirkner> and let it continue
[21:09]  * LarstiQ usually does 'import pdb; pdb.set_trace()' in the code directly
[21:09] <ricardokirkner> so I have seen that the auth.py code that handles credentials is not being called
[21:09] <ricardokirkner> yes its the same
[21:10] <LarstiQ> ricardokirkner: specifically SubversionCredentialStore.decode_password?
[21:10] <ricardokirkner> specifically create_auth_baton
[21:10] <ricardokirkner> and from there downwards
[21:10] <LarstiQ> ricardokirkner: for debugging, I'd next look at get_credentials in bzrlib/config.py
[21:12] <ricardokirkner> alright
[21:13] <ricardokirkner> what I just saw is that if I dont specify the credentials in the url, it fails; if I do, the default http credentials stuff is being called
[21:13] <ricardokirkner> I will look at the config stuff now
[21:13] <LarstiQ> ricardokirkner: I'm not convinced create_auth_baton is meant to be called even
[21:14] <LarstiQ> ricardokirkner: is the regular credentials stuff also called if you provide a username, but no password?
[21:15] <ricardokirkner> LarstiQ, exactly, if I provide the username as part of the url, the http credentials handler is called
[21:15] <ricardokirkner> and prompts for a password
[21:15] <ricardokirkner> after I enter the password everything works fine
[21:15] <LarstiQ> ricardokirkner: hmkay
[21:15] <james_w> I seem to remember something about putting something in authentication.conf to allow bzr-svn to provide the credentials
[21:15] <ricardokirkner> another possibilty is that the SvnRaTransport is not being added to the list of possible_transports
[21:15] <LarstiQ> ricardokirkner: this area certainly has bugs that need squashing
[21:15] <LarstiQ> ricardokirkner: right
[21:16] <ricardokirkner> so, once it fails trying with the default handler, it exits
[21:16] <ricardokirkner> I am not sure thought if the SvnRaTransport should be added to the list of possible_transports for the http/https protocol (althought it doesn't seem so far-fetched)
[21:27] <ricardokirkner> LarstiQ, ok, I found a possible solution (pretty easy and straightforward too). I am not entirely sure if it is completely correct, and would like feedback on it
[21:27] <ricardokirkner> I basically registered SvnRaTransport as lazy transport for the http and https protocols, in the __init__.py file of the svn plugin
[21:28] <ricardokirkner> and it works (with the minimal testing I did so far)
[21:28] <ricardokirkner> if this is alright.. what steps should I do to include this fix into bzr-svn?
[21:29] <ricardokirkner> (btw, another solution that works, is to add the repo to the authentication.conf file :-))
[21:29] <LarstiQ> ricardokirkner: with password_encoding=subversion?
[21:30] <ricardokirkner> ???
[21:30] <LarstiQ> I guess not :)
[21:30] <LarstiQ> ricardokirkner: how do you add it to authentication.conf?
[21:30] <ricardokirkner> no, in the authentication.conf file I just specified username, password
[21:30] <LarstiQ> ah, well, yes :)
[21:30] <ricardokirkner> and host
[21:30] <ricardokirkner> but the other approach (registering the transports in __init__.py) seems better (less intrusive on the user)
[21:31] <ricardokirkner> what do you think?
[21:31] <LarstiQ> ricardokirkner: I don't know the code well enough to judge if that is a correct thing to do.
[21:31] <LarstiQ> ricardokirkner: one issue for example is not loading the svn plugin until it is really needed
[21:32] <ricardokirkner> alright... what's the usual approach here? should I branch the bzr-svn code, fix the code in my branch, submit a bug request, and submit a possible solution pointing to my branch for review?
[21:32] <LarstiQ> ricardokirkner: yes
[21:32] <ricardokirkner> ok
[21:32] <ricardokirkner> will do that now
[21:32] <ricardokirkner> thanks a lot for the 'mentoring' :-)
[21:32] <LarstiQ> no problem :)
[21:33] <LarstiQ> ricardokirkner: for the last part, linking the branch to the bug is what I'd do
[21:33] <ricardokirkner> ok
[21:44] <james_w> I think password_encoding is the way it is supposed to be enabled
[21:47] <LarstiQ> james_w: is that a choice not to use credential stores unless explicitly told to?
[21:47] <james_w> I believe so, but a debated one
[21:47] <LarstiQ> yeah, I believe the out of the box experience for svn at least should be better
[23:07] <ricardokirkner> james_w, yes, I agree with LarstiQ
[23:07] <ricardokirkner> I am almost new to the bzr codebase
[23:07] <ricardokirkner> but I have seen there is the possibility to register several transports for a protocol
[23:07] <ricardokirkner> the problem is that when the first transport fails, the next ones are not tried out
[23:08] <ricardokirkner> maybe if we allow to iterate over all transports, until we reach one that succeeds, it would be just a matter of registering several transports for http/https
[23:09] <ricardokirkner> (e.g. register the svn transport if it exists as the first one, and fall back to the default transport for http if the svn one fails)
[23:10] <ricardokirkner> james_w, btw, if you could point me to the thread where this was discussed, it would be really helpful
[23:11] <ricardokirkner> as, currently, one of the greatest benefits of git for me right now, is that it supports svn out of the box; I wish I could have that issue less in my comparison between bzr and git , as I would really like to continue using bzr as my default vcs
[23:11] <james_w> I only remember the discussion about whether the methods should have to be declared from IRC, sorry
[23:12] <james_w> if you post to the list or file a bug then it would probably revive the discussion
[23:12] <ricardokirkner> james_w, alright.
[23:17] <ivan> if you want to make a small fix to all of your very different branches, what's the right thing to do?
[23:18] <ivan> make it in one and cherry-pick it to everywhere?