[00:00] <RenatoSilva> hm sorry, that's not what I want
[00:00] <RenatoSilva> I want to diff the whole tree in rev 146 and current uncommitted version
[00:01] <RenatoSilva> just like the current revision was 146
[00:01] <RenatoSilva> (that command would work as I expect in this case)
[00:07] <chx> how can i check the version of a checkout? neither bzr status nor bzr info tells me :(
[00:07] <poolie> bzr revno
[00:08] <chx> curious. i have two chkecouts, one works, the other throws an APC error (yeah, php webapp) and according to bzr revno they are the same rev?
[00:09] <chx> oh well. we will figure it out, thanks
[00:11] <poolie> chx: are they checkouts of the same branch? are they both clean?
[00:11] <chx> yes and yes
[00:11] <chx> and they even look the same because i checked a file i changed fairly recently but wait...
[00:11] <chx> you gave me an idea
[00:13] <poolie> at this point i would probably 'diff -r' them to get a plain diff without any bzr complications
[00:13] <chx> hrm, there is a settings file unversioned in his dir but cant cause anything liek this... weiiiiiird. i will just chalk it up to APC.
[00:13] <poolie> in case something is unversioned or ignored
[00:15] <mwhudson> diff -r -x .bzr :)
=== Adys is now known as Shirvallah
=== Shirvallah is now known as Adys
=== samurai_ is now known as samiam
[04:02] <igc> hi all
[04:14] <igc> poolie: was that a tweak vote for the What's New in 2.2 doc?
[04:15] <poolie> igc, i'm not overriding vila but otherwise yes
[04:15] <poolie> so it's up to you to decide if you want to block on him
[04:16] <igc> poolie: ok. I'll ping him later today and see if I can make us both happy
[04:19] <cody-somerville> If I upgrade a branch, can I downgrade it if I run into issues?
[04:19] <bob2> not if you upgrade to a rich-root-format
[04:19] <bob2> (from a non-rich-root format)
[04:19] <cody-somerville> What does the "upgrade this branch" action on launchpad do?
[04:20] <RAOF> Basically runs “bzr upgrade $THE_BRANCH” on the launchpad server.
[04:20] <cody-somerville> The branch currently works with bzr 1.13.1, 2.0.2, and 2.1.0. If I upgrade the branch, will any of those versions no longer be able to interact with the branch?
[04:21] <mwhudson> cody-somerville: 1.13.1
[04:21] <mwhudson> (it needs 1.16+)
[04:22] <RAOF> But bzr+ssh will work all the way back to 1.6, won't it?
[04:29] <spiv> RAOF: bzr+ssh unfortunately does not fully isolate the client from the remote format
[04:30] <spiv> RAOF: we'd like to get to that point, but haven't yet.
[04:31] <mwhudson> and i guess crowberry's ram thanks you for that so far
[04:31] <RAOF> Oh, really?  I seem to recall testing that 1.6 would branch at one point; maybe I misremember or didn't check hard enough.
[04:33] <spiv> I suspect you misremember; the hpss client has always checked the remote format string and expected to recognise it.
[04:33] <lifeless> spiv: not true
[04:34] <lifeless> spiv: very early hpss was sftp only
[04:34] <lifeless> sorry, VFS only
[04:34] <Peng> That contradicts what spiv said?
[04:34] <mwhudson> lifeless: wouldn't that mean that the _server_ wouldn't have to understand the branch format?
[04:35] <lifeless> mwhudson: right, I suspect i just failed to read now.
[04:35] <Peng> Hmm, if you use nosmart+bzr+ssh, will the servef still ignore the format?
[04:35] <Peng> server*
[04:35] <lifeless> yes
[04:35] <Peng> Neat.
[04:36] <lifeless> [modulo bugs]
[04:37] <Peng> Yes, that's exactly what I was worried about...
[04:47] <spiv> lifeless: well, except that the VFS behaviour also checks the remote format too :P
[04:48] <lifeless> spiv: yes, server side doesn't. I was misreading.
[04:49] <spiv> Ah.
[04:59] <parthm> vila: hi
[05:17] <Supertanker> How do I set my local branch back to a specific revision?
[05:21] <Peng> Supertanker: In what way? Do you just want to revert the working tree or actually remove later revisions from history?
[05:21] <Peng> Supertanker: Anyway, "bzr revert -r 123", "bzr update -r 123" (in a recent bzr) or even "bzr uncommit -r 123" are what you want.
[05:22] <Supertanker> Peng, ah, okay, as usual, I have fine-grained control. Thanks :)
[05:39] <NyRy> had a question about creating new sub-directories in a directory that belongs to a branch
[05:40] <NyRy> Do I need to issue the command add again?
[05:41] <bob2> you need to tell bzr to add anything you would like it to care about
[05:41] <bob2> as a shortcut, 'bzr mkdir' mkdirs then adds
[05:42] <NyRy> bob2: I can see in bzr status that bzr has a few directories as "unknown"
[05:42] <NyRy> Can I use the bzr add command at the parent level or do I need to add each sub-directory individually?
[05:43] <NyRy> should back up and say that I'm using bzr to vc my web root on my server
[05:43] <NyRy> I did an initial add, but since new directories have been added
[05:43] <bob2> presumably you did 'bzr add .' then, so you know the answer now :)
[05:44] <NyRy> Trying to figure out if I can use "bzr add" at the web root to recursively add everything new or if I have to add each new directory individually
[05:44] <bob2> yes, of course
[05:44] <bob2> surely that's how you added stuff originally?
[05:44] <bob2> don't forget to carefully check the output of 'bzr status' before committing
[05:44] <bob2> so you don't commit junk
[05:44] <NyRy> yes, originally did bzr add, but can I do that again
[05:45] <NyRy> not sure since somethings from the orig add are already in the repository
[05:46] <NyRy> Sorry if this sense basic, but I'm not 100%
[06:17]  * igc food
[06:25] <neaj> when i 'bzr merge http://svn.repo/...', bzr pulls all 300+ revisions before telling me "Branches have no common ancestor" .. can't it fail faster?
[06:33] <poolie> neaj: perhaps in principle it could
[06:33] <poolie> you could file a bug against bzr-svn
[06:37] <neaj> OK thanx .. i guess it's no problem with a fat pipe, but i'm not that well-connected
[06:37] <poolie> there might be something about the svn protocol that makes it hard to do quickly
[06:37] <poolie> i'm not sure
[07:14] <vila> hi all !
[07:14] <vila> poolie: hey patch pilot :)
[07:23] <poolie> hello vila
=== poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.0 is out
[08:33] <lifeless> poolie: tomorrow can you reply to my end-of-rotation email?
[08:34] <poolie> sure
[08:34] <lifeless> the one I sent friday
[08:34] <lifeless> its the sort of email to which silence makes one nervous ;)
[08:34] <poolie> i was waiting for david to agree or whatever
[08:34] <poolie> but i'll reply
[08:34] <lifeless> heh.
[08:35] <lifeless> tjanks
[08:35] <lifeless> mkanat: ISE's on loggerhead:( - #launchpad
[08:46]  * igc dinner
=== marienz_ is now known as marienz
[09:45] <xterm> Hello, is it possible to get a file back from repository if i delete it locally without having to re-checkout the entire repo ?
[09:49] <neaj> poolie: jelmer lobbed the issue back at you ;-]
=== jelmer_ is now known as jelmer
[09:50] <jelmer> sorry :-)
[09:50] <Peng> xterm: Just the current copy? "bzr cat bzr+ssh://...."
[09:50] <Peng> xterm: Might still download a decent chunk of data, though.
[09:53] <neaj> i feel strange .. the bzr channel is bizarely friendly .. (in comparison to most channels I visit)
[09:54] <xterm> Peng, thank you.
[09:55] <idnar> bzrly? :D
[09:57]  * Peng revokes idnar's pun license
[10:01] <lifeless> neaj: we try ;)
[10:01] <idnar> heh heh
[10:01] <lifeless> idnar: -groan- :P
=== bigjools is now known as bigjools-otp
=== bigjools-otp is now known as bigjools
[10:45] <dvheumen> hi, I've got a question about running the bzr selftest. I've created a branch of lp:bzr/2.0 and I try to run the selftest, but either 2.0 contains errors (according to the test) or it might be that the selftest modules of the *installed* version (2.1) are used. Can I somehow find out what modules are in use?
[10:45] <dvheumen> I'm running the selftest like: <bzrdir>$ ./bzr selftest
[10:49] <lifeless> dvheumen: that should be fine. whats erroring?
[10:49] <spiv> dvheumen: you can check what './bzr --version' reports
[10:49] <lifeless> dvheumen: and have you run make?
[10:49] <dvheumen> I just noticed this warning before the actual testing starts: "Unable to load plugin 'news_merge' from '/usr/lib/python2.6/dist-packages/bzrlib/plugins'". This seems to confirm my suspicions.
[10:49] <dvheumen> no I haven't run make, is this necessary?
[10:50] <spiv> dvheumen: ah, ./bzr will still try to load the system-wide plugins I guess
[10:50] <dvheumen> is there any way around this? maybe set PYTHONPATH or something? (I'm not at all familiar with python, yet, but I'd like to change that :P)
[10:51] <Peng> Well, --no-plugins will disable all plugins.
[10:52] <jelmer> dvheumen: alternatively you can remove the news_merge plugin in the install directory
[10:52] <jelmer> dvheumen: if you have admin rights
[10:53] <jelmer> although we'd be interested to hear why that plugin is failing to load, that seems like a bug
[10:53] <lifeless> jelmer: for < 2.1, not a bug
[10:53] <lifeless> jelmer: early fail
[10:54] <jelmer> lifeless: ah, ok
[10:54] <lifeless> jelmer: commitfromnews will work on anything; it doesn't [yet] need shiny-newness
[10:55] <jelmer> lifeless: I think this is about news_merge though
[10:55] <lifeless> jelmer: yes, I was offering a possibility that you were remembernig the other news related plugin as one that should work on 2.0
[10:56] <jelmer> lifeless: ah
[10:56] <jelmer> lifeless: sorry, monday morning syndrome
[10:56] <lifeless> de nada
[10:59] <dvheumen> but, I'm still curious, now that I run the selftest with '--no-plugins', is it assured that it runs the 2.0 selftest modules that are in the branch instead of the modules in /usr/lib/python2.6/dist-packages/bzrlib? (And how could I check this?)
[11:01] <lifeless> yes, and by using python to inspect the various modules __file__
[11:01] <lifeless> we set the path for bzrlib.plugins explicitly, other than that we use the defaults, and its the manual setting that loads plugins from the system install
[11:02] <dvheumen> okay thanks
[11:34] <persia> Good day.  Is there a way to untag akin to uncommitting?
[11:35] <Peng> persia: bzr tag --delete
[11:36] <Peng> persia: As with uncommit, it's hard to get rid of the tag from any branches you've pushed to, though. bzr push --overwrite and bzr tag --delete are you friends there.
[11:36] <persia> Peng: Thanks.  There's always an option I fail to find :)
[11:36] <Peng> your*
[11:36] <persia> I used to use push --overwrite a lot, but I've become more conservative about push :)
=== salgado is now known as salgado-brb
=== mrevell is now known as mrevell-lunch
[12:57]  * LeoNerd ponders  bzr pushover  as an alias for  push --overwrite
=== weigon_ is now known as weigon
=== mrevell-lunch is now known as mrevell
[13:48] <dvheumen> hi, about the question i asked earlier (regarding the selftest running system-wide plugins even though it is run from a local branch directory). It seems to me that it is worth mentioning something about that in the Bazaar Testing Guide. Do you agree?
[13:49] <Peng> If it includes other semi-rare gotchas, then yes, that sounds good to me.
[13:49] <Peng> (Not that I'm an authority on this.)
[13:50] <dvheumen> Peng, what do you mean by 'other semi-rare gotchas'? Other than that it might result in errors/warnings/unloadable plugins if the modules do not correspond to the bzr version being tested?
[13:51] <Peng> I mean that it's not a super-common issue. If the guide is very high-level, I'm not sure it warrants mentioning
[13:51] <Peng> But if the guide goes into other things, and you think it fits well, it sounds good to me.
[13:53] <dvheumen> okay, well that's exactly why I ask. The point is, I'm just starting with python development so I might encounter things that to others might seem obvious. I'd like to help, but stating the obvious is not that interesting :P
[13:56] <Peng> It's not obvious, IMO. It's a good thing to warn people about. It's just...it's not a problem people will run into *that* frequently, and I don't know if the testing guide is the kind of document that should include such warnings. (I don't know because I haven't read it.)
=== salgado-brb is now known as salgado
[14:01] <dvheumen> okay tnx, I'll think about it :P
[15:47] <jam> morning all
=== salgado is now known as salgado-lunch
[16:08] <maxb> jelmer: hello from yesterday
[16:10] <jelmer> maxb: hello
[16:10] <jelmer> maxb: I remember pinging you, just need to figure out why :-)
[16:10] <maxb> ah :-)
[16:11]  * kfogel is away: reboot
[16:12] <jelmer> maxb: You had an open merge proposal against one of the bzr-rebase branches that I removed
[16:12] <jelmer> if it still applies, can you please resubmit it?
[16:13] <maxb> ah, so I did. It's been hanging around on my "Do I need to rethink this logic one more time?" pile
[16:13] <maxb> I actually have four separate bzr-rewrite branches at various stages of completeness :-/
[16:24] <jelmer> maxb: heh, ok
=== beuno is now known as beuno-lunch
=== salgado-lunch is now known as salgado
[16:58] <dvheumen> hi. I'm trying to do some (first-time) bugfixing for bazaar. I've selected myself a bug and now I've got some questions about how to approach the test case(s). (I noticed that the patch pilot is currently not online, but maybe someone else can help?) It's about bug: https://bugs.launchpad.net/bzr/+bug/498409 I've selected it to not be too complicated, but maybe the bug itself is even rediculously simple (or I don't get it :P)
[16:58] <ubottu> Launchpad bug 498409 in bzr "bzr revert takes a branch lock" [Medium,Confirmed]
[17:00] <jelmer> dvheumen: hi
[17:00] <jelmer> dvheumen: I think that's a fairly tricky thing to test
[17:01] <jelmer> fixing the bug without a test would be simpler, but alternatively, could I suggest picking a different bug?
[17:03] <dvheumen> jelmer, this is the fix I have now. http://paste.ubuntu.com/391170/
[17:03] <dvheumen> I could pick another bug, I don't mind, but if it is this simple ...
[17:04] <dvheumen> the code is in the 'cmd_revert' class
[17:04] <jelmer> dvheumen: that looks reasonable enough
[17:04] <jelmer> dvheumen: Perhaps submit this as a merge request and ask the patch pilot for further guidance?
[17:04] <dvheumen> should I just make it a branch and then pick a more suitable bug? :)
[17:05] <dvheumen> okay, I'll do that
[17:05] <jelmer> dvheumen: I think there might be a helper class that can remember the locking that has been done on a tree somewhere, but I don't have time to look for it atm.
[17:06] <jelmer> Martin should be able to help you out with that bit though.
[17:07] <dvheumen> jelmer, okay, so that's how you approach such a case. Okay, I'll ask Martin and in the mean time I'll have a look for the class. Thanks
[17:07] <dvheumen> I do know how to pick the wrong bugs :P
[17:08] <jelmer> dvheumen: yeah, that's the pattern we usually use for things like that.
[17:11] <jam> vila: are you still around?
[17:11] <jam> (just wanting to say hi)
[17:12] <vila> jam: yeah, hi ! I thought you were in vacations and without internet access ?
[17:12] <jam> no, starts on Wed night
[17:12] <jam> 10th
[17:12] <vila> oooh, ok
=== deryck is now known as deryck[lunch]
[17:13] <jam> anyway, I hope you had a decent weekend
[17:13] <jam> I saw your went offline briefly, (on Fri?)
[17:13] <jam> power outage?
[17:14] <vila> yeah, a planned one
[17:14] <vila> of course it took longer than planned :-/
[17:16] <dcraven> Is there a way to "name" a shelved change so that you can later retrieve it by that given name rather than the assigned number?
[17:16] <vila> dcraven: bzr shelve -m name
[17:16] <vila> dcraven: but you still need to use the number obtained from 'bzr shelve --list'
[17:16] <dcraven> Oh. Something tells me I missed an obvious bit of the doc :)
[17:16] <dcraven> vila: That's good stuff. THanks.
[17:17] <vila> dcraven: may be :-) But if you didn't file a bug asking for clarifications :)
[17:17] <vila> dcraven: may be :-) But if you didn't, file a bug asking for clarifications :)
[17:17] <vila> comas are important...
[17:17] <dcraven> vila: Oh I did see that. I think I mis-interpreted the function of "message".
[17:18] <vila> ok
[17:18] <jam> vila: commas are important, too
[17:18] <vila> jam: hehe, I can't fix a typo without doing another one, story of my life :)
=== jkakar_ is now known as jkakar
=== beuno-lunch is now known as beuno
=== deryck[lunch] is now known as deryck
=== IslandUsurper is now known as IslandUsurperAFK
=== radoe_ is now known as radoe
[18:45] <marv> so i was reading up on bzr, and finally found something I don't like. apparently if you 'bzr merge' and then 'bzr push' it will mess up the remote side's history (making it match the local side). Is there any way around that besides following the "best practice" that involves making all changes in a separate branch and merging that into clone of the central one and pushing?
[18:45] <beuno> marv, yes
[18:45] <beuno> set a variable on the server side
[18:46] <beuno> I can't remember off the top of my head
[18:46] <beuno> but it's something like append_only = True
[18:46] <marv> beuno: i saw a reference to that. something like history append only?
[18:46] <james_w> well, that forces you to use that workflow
[18:46] <marv> but from what I was reading, that only makes the push that would mess things up fail
[18:47] <marv> I'm wondering why there can't just be an option to 'push' (or maybe the default) to make it work in a way that doesn't rewrite history remotely
[18:48] <james_w> not really
[18:48] <james_w> you could provide an alternative to merge that allowed you to avoid this situation if used at the right time
[18:49] <marv> in one of the threads i saw, someone said they were going to ask for a merge --remote flag or something
[18:50] <marv> i guess you could rebase instead of merging, but I'm not sure I like that
[18:54] <marv> but it seems like there should be like a 'push as merge' command that makes the remote side end up as if I had done all those extra steps but without me having to do them.
=== IslandUsurperAFK is now known as IslandUsurper
[18:56] <asabil> marv, that's because merge is asymmetric
[18:57] <asabil> if you instead keep a checkout of trunk, and always merge into trunk then that should be fine
[18:59] <marv> why should i have to do that? that seems like a UI wart to me. you're asking me to do several extra steps that could all be automated. and the most obvious way of doing things doesn't do what I want. And I see other projects with guides that say you have to follow this certain workflow or you'll mess up our history.
[19:05] <lifeless> marv: so, its automatable in principle. Its just code.
[19:06] <lifeless> marv: so far, noone has done a really nice automated version that preserves digital signatures and so on.
[19:07] <marv> lifeless: interesting. so someone is or was working on it then?
[19:08] <lifeless> there was at least one plugin offering what you describe
[19:09] <marv> any idea what it was called? it might be a good place to start
[19:11] <wadesworld> is there a way to change an existing branch to a different connection method?  i.e. I did bzr branch sftp:// and now I want to change the connection method to bzr+ssh://
[19:11] <wadesworld> can that be done, or is the only way to branch a new copy with bzr+ssh?
[19:17] <maxb> wadesworld: bzr pull --remember otherurl
[19:17] <wadesworld> cool, thanks :)
[19:29] <lifeless> marv: remotemerge, I think
[19:43] <nvsbl> can someone help me?
[19:43] <nvsbl> after i encrypted my home drive (using this guide: http://jacob.hoffman-andrews.com/README/index.php/2009/12/08/howto-encrypt-an-existing-home-directory-on-ubuntu-karmic-koala/)
[19:43] <nvsbl> bzr suddenly stopped working
[19:44] <nvsbl> now i get this:
[19:44] <nvsbl> Permission denied (publickey).
[19:44] <nvsbl> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
[19:45] <jpds> nvsbl: That sounds more like an SSH error.
[19:48] <marv> lifeless: thanks
[19:51] <marv> although i can't find anything on it with google
[20:25] <maxb> nvsbl: Are you saying you encrypted the homedir on the remote server or the local machine that you're running bzr on? (Either way it's still a SSH problem)
[20:28] <nvsbl> the local machine
[20:29] <nvsbl> is there a specific place i can go to ask for help
[20:29] <nvsbl> perhaps a specific forum or irc channel?
[20:30] <lifeless> well we can try to help you
[20:30] <maxb> I can't think of an obvious place for generic ssh help (other than #ubuntu, which is useless because it's so high volume)
[20:30] <lifeless> does 'ssh <host>' work
[20:30] <lifeless> what does it output
[20:30] <lifeless> what does ssh -vv <host> output
[20:30] <lifeless> etc
[20:32] <nvsbl> what should the host be if i were trying to get something off launchpad?
[20:33] <maxb> bazaar.launchpad.net
[20:33] <maxb> In that case, it would say "No shells on this server." if it's working correctly
[20:35] <nvsbl> .....No such Launchpad account: nvsbl
[20:35] <nvsbl> debug1: Authentications that can continue: publickey
[20:35] <nvsbl> debug1: Trying private key: /home/nvsbl/.ssh/identity
[20:35] <nvsbl> debug1: Trying private key: /home/nvsbl/.ssh/id_dsa
[20:35] <nvsbl> debug2: we did not send a packet, disable method
[20:35] <nvsbl> debug1: No more authentication methods to try.
[20:35] <nvsbl> Permission denied (publickey).
[20:36] <nvsbl> why does it think my launchpad account is that? that isn't my account and i'm logged in as my real account
[20:38] <nvsbl> http://paste.ubuntu.com/391265/ if having the entire output helps
[20:38] <awilkins> nvsbl, Try  `bzr launchpad-login <your launchpad account name>`
[20:38] <nvsbl> i did
[20:38] <nvsbl> same thing
[20:40] <maxb> nvsbl: Of course, `bzr launchpad-login` only affects bzr. If you're testing it with ssh manually, you'll need to say `ssh your-lp-id@bazaar.launchpad.net`
[20:42] <nvsbl> http://paste.ubuntu.com/391271/
[20:42] <nvsbl> same thing, still
[20:42] <servilio> hi all!
[20:43] <servilio> I am still struggling with importing from svn
[20:43] <servilio> using bzr 2.1 & bzr-svn 1.0.2
[20:43] <NfNitLoop> servilio: Struggling how?
[20:43] <servilio> no matter what I try, I end up with an empty repository
[20:43] <servilio> branch, whatever I make
[20:44] <NfNitLoop> as in, 'bzr log' doesn't show any revisions?
[20:44] <NfNitLoop> or as in, it lacks a working copy?
[20:44] <servilio> NfNitLoop: yep, an empty log
[20:44] <NfNitLoop> do you get an error?
[20:44] <servilio> NfNitLoop: no error
[20:44] <NfNitLoop> are you able to svn checkout the same URL?
[20:44] <servilio> command used: bzr svn-import --verbose file://$PWD/repo-svn/plone/mcmaster.branding.theme repo-bzr/mcmaster.branding.theme
[20:45] <servilio> NfNitLoop: let me try...
[20:45] <servilio> NfNitLoop: oh, wait, I can do svn ls no problem
[20:45] <NfNitLoop> Hrmm, strange.
[20:45] <servilio> NfNitLoop: and checkout too, just did it
[20:46] <servilio> I've tried creating a shared repo, and a standalone branch, and a branch inside a shared repo
[20:46] <servilio> no luck
[20:46] <NfNitLoop> anything interesting in ~/.bzr.log ?
[20:47] <servilio> let me see
[20:47] <NfNitLoop> (please use a pastebin for anything over a couple lines)  :)
[20:48] <servilio> no error
[20:48] <servilio> was about to ask what pastebin to use :D
[20:48] <NfNitLoop> Ehh, doesn't matter to me.
[20:48] <NfNitLoop> I don't see one in the topic.
[20:48] <servilio> me neither
[20:49]  * servilio goes to search for a paste
[20:51] <NfNitLoop> http://ubuntu.pastebin.com/
[20:54] <maxb> servilio: You should not need to create anything at all before running `bzr svn-import`
[21:00] <servilio> maxb: that's what I thought, but that didn't work either
[21:00] <servilio> NfNitLoop: http://paste.lisp.org/+226A
[21:00] <maxb> Looks to me as if bzr-svn is having trouble understanding your svn repository
[21:01] <maxb> Is this repository public?
[21:01] <servilio> maxb: unfortunately, no
[21:01] <maxb> hm
[21:02] <servilio> maxb: not that it could not be, I just don't have a server for it
[21:02] <servilio> maxb: public server, it is
[21:03] <NfNitLoop> strange, that log seems to think it found 21 revisions.
[21:03] <maxb> Well, the easiest way for someone else to understand the problem would be for them to see if happening
[21:03] <NfNitLoop> and it explicitly says that it didn't create a working copy.
[21:03] <NfNitLoop> did it create empty subdirectories for you?
[21:03] <NfNitLoop> with svn-import, iirc those subdirectories are your branches.
[21:03] <NfNitLoop> THEY will have your history (bzr log)
[21:05] <servilio> NfNitLoop: when pointing to a non-existing directory it will create it and it has a .bzr directory inside
[21:06] <NfNitLoop> and 'bzr log' in that directory has no revisions?
[21:06] <servilio> NfNitLoop: no revision, it even complains that it is not a branch
[21:07] <NfNitLoop> is mcmaster.branding.theme a branch?   Or does it contain trunk/ branches/ and tags/ ?
[21:07] <servilio> bzr info says it is a shared repo
[21:07] <NfNitLoop> nono, the one in your SVN repo.
[21:07] <servilio> NfNitLoop: it contains the regular trunk/branches/tags structure
[21:07] <NfNitLoop> ah.  Hmm.
[21:07] <NfNitLoop> I don't know.
[21:08] <NfNitLoop> as I've said before, I just use 'bzr branch'.
[21:08] <servilio> by bzr info I meant when doing it on the newly imported dir
[21:08] <maxb> servilio: Could you run `svn info file://$PWD/repo-svn/plone/mcmaster.branding.theme` and pastebin please?
[21:08] <servilio> NfNitLoop: thanks anyway!
[21:08] <NfNitLoop> try doing bzr branch file://$PWD/repo-svn/plone/mcmaster.branding.theme/trunk yourNewTrunkBranch
[21:08] <nvsbl> alright, i fixed what was wrong
[21:09] <nvsbl> all i had to do was create a new ssh key with my launchpad username
[21:09] <servilio> maxb: http://paste.lisp.org/+226D
[21:10] <maxb> servilio: Right.... I'm guessing that the problem might be with bzr-svn's layout detection
[21:11] <maxb> Just to confirm, file:///home/servilio/Trabajo/McMaster/RHPCS/Plone/code/repo-svn/plone/mcmaster.branding.theme/trunk exists?
[21:11] <servilio> maxb: yes
[21:12] <servilio> maxb: it is an existing, used repository
[21:12] <servilio> maxb: I am migrating it to bzr
[21:12] <servilio> maxb: well, trying to...
[21:12] <maxb> OK, go to your ~/.bazaar/subversion.conf and find the [c133bc4f-f41c-0410-a8f9-f4ee1c8ca9d1
[21:12] <maxb> ] section .... It says "guessed-layout = trunk3" ?
[21:12] <maxb> Change that to "layout = trunk-variable"
[21:13] <maxb> then try again
[21:13] <servilio> maxb: will try again, remember using that layout in the command line, but when trying to import the whole repo last  week instead of project by project
[21:18] <servilio> maxb: great! that created a shared repo and inside the trunk, but I only see 4 revisions from the 40+ that are in svn
[21:19] <NfNitLoop> servilio: it'll only get revisions that are actually IN trunk.
[21:19] <NfNitLoop> try doing svn log on file:///home/servilio/Trabajo/McMaster/RHPCS/Plone/code/repo-svn/plone/mcmaster.branding.theme/trunk
[21:19] <NfNitLoop> it likely only has 4 revisions in it.
[21:19] <servilio> NfNitLoop: already did ;)
[21:20] <servilio> doing "svn log file://$PWD/repo-svn/plone/mcmaster.branding.theme/| grep ^r | wc -l" outputs 55
[21:22] <NfNitLoop> Hrmm.
[21:23] <NfNitLoop> servilio: at some point in its history, was trunk/ moved?
[21:23] <NfNitLoop> maybe it's only showing history since trunk has been at its new location?
[21:23] <NfNitLoop> (I'm not quite sure how that works.)
[21:27] <servilio> NfNitLoop: if I add --stop-on-copy the log stops at 34
[21:29] <servilio> NfNitLoop: maybe that together with something else, but not the moving/renaming of the repository alone
[21:31] <NfNitLoop> servilio: well, does the bzr branch at least accurately reflect the current state of trunk?
[21:32] <servilio> NfNitLoop: haven't checked that yet
[21:32] <servilio> NfNitLoop: kept myself busy trying to find a way to keep the history
=== salgado is now known as salgado-afk
[21:38] <NfNitLoop> well, if it has the right content, it's a matter of bzr representing history as best it can.
[21:38] <NfNitLoop> if it has the wrong content, it's a bug in bzr.
[21:38] <NfNitLoop> those have two different solutions. :)
[21:39] <cody-somerville> Thank you bzr developers for making me not have to worry about 'default branches', 'fast forwarding', and other git hell.
[21:46] <NfNitLoop>  hehe.
[21:46] <NfNitLoop> cody-somerville: amenn to that!
[21:48] <NfNitLoop> What is a default branch and fast forwarding? :p