[00:05] <AfC> asac: ping
[00:12] <sttng359>  how do I remove a branch from a shared repository?
[00:13] <bob2> rm
[00:14] <sttng359> but won't that leave copies of the data in the repo?
[00:14] <sttng359> I know I can safely rm a standalone tree, but this branch has nothing worth saving.
[00:14] <bob2> yes
[00:14] <bob2> don't think there's a 'bzr gc' command yet
[00:14] <bob2> so if you really care, afaik, you'd have to make a new repo and branch everything to it
[00:15] <sttng359> ok
[00:16] <sttng359> hmm, bzr pack wouldn't do garbage collection would it?
[00:17] <Peng> It does not do garbage collection.
[00:17] <Peng> That is, it doesn't remove anything. It just organizes and compresses it more efficiently.
[00:20] <sttng359> Is a gc command on the roadmap?
[00:21] <spiv> It would be nice to have, there's a bug report for it somewhere, but it's not a priority.
[00:24] <sttng359> yea, I suppose I didn't have gc with svn after all.  Deleting branches in svn only add to diskspace requirements.
[00:44] <sttng359> hmm, what about bzr reconfigure --standalone and rm?
[00:44] <sttng359> will that remove extra copies from the repo or do copies always stay in the repo?
[00:44] <bob2> I'd be very surprised if that removed all the now-unneeded revision data from the repository
[00:45] <sttng359> I suppose the repo just doesn't track which branches are using it so the above would be very difficult.
[00:46] <Peng> Right.
[00:46] <Peng> When you get into stacked branches, remote clients and stuff, it becomes impossible.
[00:52] <dcoles> jelmer: Here's the bug report for that bzr-svn authentication.conf bug I was having https://bugs.launchpad.net/bugs/532292
[00:52] <dcoles> urlparse.urlsplit doesn't like 'svn+https' urls :S
[00:57] <jelmer> dcoles: I've just fixed it :-)
[00:58] <dcoles> jelmer: Cheers :)
[00:59] <jelmer> dcoles: thanks for the detailed bugreport, that made it really easy to fix.
[01:01] <maxb> Has anyone encountered bzr-svn corrupting its cache.tdb if Ctrl-C'ed whilst caching new revisions?
[01:01] <dcoles> jelmer: I do a lot of python programming for work... and bazaar being python based makes it really easy to hack on ;)
[01:02] <maxb> It seems to manifest as some paths/<revno> keys going missing from the tdb
[01:02] <jelmer> maxb: I've seen it, I'm 99% sure it's because of the "svn log" fetch reversal patch that went in for 1.0.2
[01:02] <maxb> ooh, that would entirely explain it - log-last is ending up pointing to a higher number than completely cached
[01:03] <jelmer> maxb: I haven't had time to look into it yet, but if you can provide a bug report/patch that would be most welcome :-)
[01:03]  * maxb will have a think. Unfortunately I guess you reversed the fetching for a reason, and fixing it without just backing it out doesn't seem obvious
[01:04] <jelmer> the reversing is done because svn servers are quicker if asked for the revision data from newest to oldest
[01:07] <maxb> The "obvious" way to fix this would be to bin log-min and log-last and store a list of ranges which are cached
[01:07] <maxb> but that's a compatibility can of worms, I suppose
[01:15] <mwhudson> jelmer: this one failed in discovering tags, i think: http://launchpadlibrarian.net/40213543/vcs-imports-sit-trunk-log.txt
[01:19] <jelmer> mwhudson: there's an open bug about that issue
[01:19] <jelmer> mwhudson: would be nice if we could associate bugs with import failures (-:
[01:19] <mwhudson> jelmer: oh cool
[01:20] <mwhudson> jelmer: well yeah, i'll do the unsophisticated whiteboard/comment thing i guess
[01:21] <MTecknology> What's your opinions about keeping documents stored in a bzr branch?
[01:24] <mwhudson> jelmer: hm, it seems none of the 5 vaguely similar bugs is in tag discovery
[01:24] <jelmer> mwhudson: it's not really the tag discovery that's relevant but rather the code that infers the revision graph from a svn repo
[01:25] <mwhudson> jelmer: oh ok
[01:25] <Traveler2> Hi, I want to use bzr in the following scenario.  I have some html files on a server.  I want several people to edit them using bzr.  How should I set this up?  I setup the server, did init-repo, copied the html in here, did 'bzr init' in the html folder.  Then my devs can branch fine.  But if they push, the worknig tree isn't updated.  How should I set up the repository?
[01:25] <jelmer> mwhudson: I think bug 384192
[01:25] <mwhudson> jelmer: then probalby all these bugs are duplicates: https://bugs.edge.launchpad.net/bzr-svn/+bugs?field.searchtext=Tried+registering
[01:27] <jelmer> mwhudson: yep, thanks!
[01:27] <mwhudson> np :)
[01:28] <jelmer> MTecknology: it's up to you :-) Should work well, although diff probably isn't much use if they're binary documents. And if the documents are *very* large (gigabytes) it's probably also a bad idea.
[01:28] <jelmer> Traveler2: check out the bzr-upload plugin
[01:29] <MTecknology> jelmer: It won't be a lot of massive files, the only thing I'm not sure about is, when they delete a file or alter it and the diff is just the replaced file; then that .bzr they always have to pull down will get massive pretty quick
[01:31] <jelmer> MTecknology: how big the deltas are going to be depends on the document format really
[01:31] <Traveler2> jelmer: thanks, but with this plug-in does it mean no repository is kept on the server?  Will revision history be shared with other developers this way?
[01:32] <jelmer> Traveler2: the plugin is used independently
[01:32] <jelmer> Traveler2: I assume you don't want to push your history to the same location as your web site, as that would mean visitors of your web site could access the source code and the history.
[01:32] <MTecknology> jelmer: ya lost me with the word delta
[01:33] <MTecknology> jelmer: probably mostly pdf and mso 2007 docs
[01:33] <jelmer> MTecknology: the binary diff between the old and new version of a file
[01:34] <MTecknology> jelmer: oh
[01:34] <MTecknology> hrm... I think I just figured out exactly what I want to do :D
[01:34] <Traveler2> jelmer: I do want to push it there, it's just html and I take care of people accessing it with apache
[01:35] <MTecknology> jelmer: thanks, I'll try out diffs from changing some things
[01:35] <jelmer> Traveler2: in that case you might be interested in the push-and-update plugin
[01:36] <jelmer> MTecknology: I should say, "bzr diff" isn't a good indication of the size of the data that's going to be stored
[01:37] <MTecknology> jelmer: I suppose if I just make a new branch for every year I won't need to worry about the size that much
[01:37] <Traveler2> jelmer: cool, thanks again!
[01:38] <MTecknology> jelmer: thanks for the info, I'll do a little trial, mess around with docs, check the diff size, see how big things grow
[01:43] <dcoles> jelmer: Looks like another small issue - passwords from authentication.conf can come back as unicode strings
[01:45] <dcoles> jelmer: Ah. Never mind. That's fixed in lp:452121
[03:08] <poolie> hello all
[03:10] <Peng> Hi. :)
[03:10] <MTecknology> hi
[03:12] <MTecknology> I'm trying to use the bazaar explorer for windows. Is there any way to use this to setup a shared key? I don't want to give this user account a password if I can help it - I prefer accepting connections with keys only
[03:13] <MTecknology> I don't even see how you can open it using a shared key if you do have one..
[03:14] <bob2> yes
[03:14] <bob2> the launchpad docs explain how
[03:14] <bob2> (assuming you mean "I'd like bzr explorer to use a ssh key to connect to my remote bzr repository via bzr+ssh/sftp")
[03:15] <MTecknology> will it let me generate the key in the bzr explorer too?
[03:16] <Kamping_Kaiser> does the lp plugin provide a shorthand way of saying 'push to a branch which isn't asociated with any project'? 'help lauchpad' only talks of projects
[03:17] <spiv> 'bzr push lp:~username/+junk/branchname'
[03:17] <MTecknology> Kamping_Kaiser: bzr push lp:~user/+junk/branch_name
[03:18] <Kamping_Kaiser> so i need to enter the whole ~username/+junk bit? ah well. thanks both :)
[03:19] <spiv> put 'export J=lp:~username/+junk' in your bashrc, then you could do 'bzr push $j/branchname' :P
[03:19] <spiv> Er, $J
[03:19] <poolie> hello all
[03:19] <poolie> hi spiv
[03:20] <MTecknology> bob2: I'm not finding the docs for that
[03:20] <Kamping_Kaiser> spiv: trying to decide if i want shorthand way enough to file a bug ;)
[03:20] <bob2> https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Next step
[03:24] <MTecknology> bob2: thanks
[03:30] <spiv> Kamping_Kaiser: you can always write a plugin to provie a junk: namespace as a shortcut to lp:~you/+junk
[03:33] <Kamping_Kaiser> spiv: much as i like the idea, i won't know enough python (any) to do that for a while
[03:34] <spiv> Kamping_Kaiser: bzrlib/plugins/launchpad/lp_directory.py would be a starting point if you felt like trying anyway ;)
[03:34] <MTecknology> ok, so I have the key generated but the bazaar explorer is still confusing me, I thought it would let you pick a key in the branch operation
[03:34] <Kamping_Kaiser> spiv: tempt me not! or i might not be able to resist :p
[03:35] <MTecknology> or do I need to put it in C:\Users\Username\.ssh or something like that?
[03:36]  * MTecknology is remembering how much it sucks to deal with windows
[03:44] <MTecknology> bob2: any chance I could just get a little more help with that?
[03:45] <spiv> MTecknology: I don't think bzr or explorer have a concept of a key per branch, if that's what you're asking?
[03:45] <MTecknology> spiv: I can't use a shared key with the bazaar explorer?
[03:46] <bob2> what do you mean when you say "shared key"
[03:46] <MTecknology> ssh key
[03:46] <bob2> ok
[03:46] <bob2> in what way do you think bzr explorer should be involved in this?
[03:47] <MTecknology> use the private key to authenticate the same way when I pull the branches in linux
[03:49] <MTecknology> bzr branch bzr+ssh://user@server/path/to/branch
[03:49] <bob2> sure, follow the launchpad page and bzr will use pageant
[03:49] <bob2> afaik
[03:50] <bob2> pretty sure it has nothing to do with bzr explorer specifically
[03:54] <Kilroo> hm...looks like my pet bug got pushed back farther.
[03:56] <MTecknology> ok... so use puttygen to create the ssh key; add public key to server; start pageant; add key to it; leave running; try to pull branch; still asks for password
[03:58] <MTecknology> hrm.. authentication (publickey) failed is showing up in the output, must be at least trying to use it??
[04:01] <MTecknology> AWESOME!
[04:01] <MTecknology> bob2: thanks - sorry if I was annoying
[04:02] <bob2> yay
[04:02] <MTecknology> I REALLY hate how windows works....
[04:02] <MTecknology> Linux, ssh-keygen; put id_*.pub on server; done
[04:02] <MTecknology> so simple :D
[04:05] <MTecknology> bob2: thanks again, time to relax :)
[05:24] <poolie> spiv, can you answer https://answers.edge.launchpad.net/bzr/+question/98083 ?
[05:24]  * spiv looks
[05:27] <spiv> Done; I've essentially just repeated jam's answer.
[05:29] <poolie> lifeless: can you have a look at https://bugs.edge.launchpad.net/bzr/+bug/528793 for me?
[05:33] <poolie> spiv, and also https://answers.edge.launchpad.net/bzr/+question/103163
[05:34] <spiv> I wonder why I don't receive question notifications.  I guess I need to subscribe somehow...
[05:34] <poolie> mm
[05:34] <poolie> i just made ~bzr-qa be subscribed
[05:35] <poolie> are the per-file merge hooks in the user guide?
[05:36] <spiv> They'll be in the hooks documentation at least, but they probably need better docs than that.
[05:45] <lifeless> poolie: http://software.intel.com/en-us/articles/itaniumr-processor-family-performance-advantages-register-stack-architecture/
[06:02] <poolie> so, spiv, could you answer that guy?
[06:02] <poolie> https://answers.edge.launchpad.net/bzr/+question/103163
[06:02] <poolie> and i'll file a bug for documenting it
[06:09] <poolie> https://bugs.edge.launchpad.net/bzr/+bug/532435
[06:11] <spiv> poolie: yes, I just did, was composing and testing the code for the answer
[06:11] <poolie> thanks
[06:11] <spiv> The code for that is still a little more complex than is ideal :/
[06:12] <poolie> urk
[06:12] <poolie> i think he was hoping for a single configuration item :)
[06:14] <spiv> Well, I suppose that plugin could be tweaked to read patterns from a .bzrmeta/fauxbinaries file ;)
[06:14] <poolie> i'd like to put it in the rules file
[06:14] <lifeless> we have too many places
[06:18] <AfC> I so wish you could have put the meta data in .bzr
[06:18] <AfC> I gather you had reasons, but it seems such a shame to have more .bzr* files than 1
[06:20] <poolie> mm
[06:20] <poolie> did any of you see a failure in https://bugs.edge.launchpad.net/bzr/+bug/532435
[06:20] <poolie> blah
[06:20] <poolie> ERROR: bzrlib.tests.test_transport.TestSSHConnections.test_bzr_connect_to_bzr_ssh
[06:21] <spiv> poolie: what sort of failure?
[06:21] <poolie> SocketConnectionError: Unable to connect to SSH host localhost:35949; [Errno 111] Connection refused
[06:21] <spiv> I haven't seen that test fail, or that type of failure in general, no.
[07:28] <vila> hi all !
[07:33] <jam> uh-oh. If I see vila wake up, I *must* need to go to bed!
[07:33] <jam> night all
[07:34] <Peng> Note to self: Impersonate vila in the middle of the afternoon to screw with jam.
[07:36] <vila> jam: eeerk
[07:36] <vila> jam: have a good night
[07:49] <SamB_XP> !localtime Peng
[07:49] <SamB_XP> aww
[08:42]  * igc dinner
[08:54] <vila> bialix, bialix, where are you ?
[09:58] <bialix> vila: hi! thanks!
[09:58]  * bialix waves hi all
[09:59] <vila> bialix: hehe, just so your Approve vote, thanks for that
[09:59] <vila> s/so/saw/
[09:59]  * bialix starting to understand vila even with typo like that
[10:01] <vila> I'm wondering if 'so' and 'saw' are pronounced differently in English in which case I'll blame my awful accent (or so cute accent depending who you ask :)
[10:05] <Peng> They are pronounced differently in my accent.
[10:06] <vila> Peng: ha good...
[10:06] <vila> Peng: ... what is your accent ? :-)
[10:06] <Peng> I don't know. Isn't it said that people don't hear their own accent?
[10:07] <bialix> say us who you are and we say what is your accent ;-)
[10:07] <Peng> vila: I'm from Florida, US.
[10:08] <vila> Peng: Well, my girlfriend recorded me lately (without notice) and I could clearly hear my accent :)
[10:08] <vila> Peng: So you're a native speaker and for bialix and me I think that counts as no accent :)
[10:08] <Peng> Heh.
[10:08] <neaj> hello all ..
[10:09] <Peng> sup!
[10:09] <neaj> i want to merge svnA into svnB using bazaar .. what's the Right Way?
[10:09] <bialix> STing has a song in French: La belle damme sans regret, it's funny to listen his accent
[10:09] <neaj> i managed to do it, but now svnB doens't have the history
[10:10] <bialix> ghost around us?
[10:10] <Peng> Hmm, what's a stereotypical southern greeting? I couldn't come up with one...
[10:10] <neaj> hi y'all
[10:10] <Peng> Ah! Good one!
[10:11] <vila> bialix: weirdo :) Listening to foreign accents in foreign foreign languages :)
[10:11] <bialix> neaj: hi, what it means "does not have the history"?
[10:11] <Peng> I can't say "y'all" with a straight face. :(
[10:11] <neaj> 'bzr log' shows only 7 revisions, but svnA has 283 revisions
[10:11] <bialix> vila: yep
[10:11] <bialix> neaj: try bzr log -n0
[10:12] <neaj> !!
[10:12]  * neaj gives bialix a noisy kiss
[10:12] <bialix> oh no
[10:12] <bialix> neaj: bonus: install QBzr and try qlog
[10:12] <neaj> OK :-)
[10:12] <neaj> wow that was a nice discovery :-)
[10:14] <vila> neaj: There should have been a message at the end of 'bzr log' (use -n0 blah blah)
[10:14] <vila> neaj: did you just miss it ?
[10:16] <vila> neaj: I'm asking to know what could have helped you discover it alone (since that's why we put the message there in the first place)
[10:29] <neaj> vila: yes, i completely missed it, sorry ..
[10:30] <vila> neaj: no no, you don't have to be sorry, instead, tell us what could have helped you notice it
[10:31] <vila> rats, I will lose *power* in ~30mins for 2 hours, I'll have to shut down properly *now*
[10:32] <vila> neaj: feel free to file a bug with your ideas
[10:33]  * vila goes back to shutting down every work in progress and migrate some stuff to the battery-powered laptop :)
[10:33] <neaj> something like this? http://pastie.org/855302
[10:35] <vila> hmm, embedding or at the top, yeah, makes sense, will not fly well with our current implementation but I think it's worth addressing for people using '| more or less
[10:36]  * vila runs
[10:40] <neaj> hmm, now is this history in svnB? when i 'svn co svnB', svn log shows only 7 revs also.
[10:41] <Peng> neaj: No. It's just in bzr.
[10:41] <Peng> I think.
[10:42] <neaj> i did: 'bzr branch svnA; bzr branch svnB; cd svnA; bzr merge -b 0..283 ../svnB; bzr commit -m "Merged"; bzr push'
[10:52] <bialix> vila: may I ask your wisdom advice? re scmproj
[10:54] <Peng> bialix: vila is gonna be AFK for the next 2 hours because of a power outage.
[10:55] <bialix> oops
[10:55]  * bialix sends vila some spare batteries
[11:10] <joey> any bzr guru's on line?
[11:10] <joey> need help to work around https://bugs.edge.launchpad.net/bzr/+bug/532550
[11:14] <bialix> joey: does this error reproducible?
[11:15] <bialix> does you have any proxy between you and lp?
[11:15] <joey> bialix: I'm trying. It happens 47 mins into my push
[11:15] <joey> bialix: probably, I'm in a hotel in London
[11:16] <joey> bialix: I'm pushing up about a 4 gig diff
[11:16] <joey> :-)
[11:16] <bialix> try to run bzr missing first to understand how many revisions you're about to push, and try then push in chunks
[11:16] <bialix> 4 gig? could be 32bit issue, maybe?
[11:16] <joey> good idea
[11:16] <bialix> sorry, I'm not really guru in 4 gig question
[11:17] <joey> oh right, I'm on a 32bit netbook not more normal 64bit system
[11:17]  * bialix summons spiv, lifeless
[11:17] <joey> 2 revs down, 1 I just did after the crash on the 1st
[11:17] <bialix> may be push in chunks would help
[11:18] <spiv> joey: ouch, big diff!
[11:18] <spiv> I doubt it's a 32-bit vs. 64-bit issue.
[11:19] <bialix> and here is: our smart server guru: spiv!
[11:19] <bialix> applause
[11:19] <spiv> joey: please add -Dhpss -Dhpssdetail to the command line, try again, and then attach the .bzr.log to the bug
[11:20] <spiv> joey: it's certainly a bug in bzr, although it's one I haven't seen before
[11:21] <spiv> joey: bialix's advice about pushing less revisions at a time is probably the best workaround I can think of.
[11:22] <spiv> joey: hmm, although sftp might be a workaround too?  'bzr push<EMAIL_ADDRESS>[11:22] <spiv> joey: I need to go to bed; please put any further info you get into the bug, I'd really like to understand what's gone wrong here.
[12:09] <joey> hmm
[12:10] <joey> I think I might have found the issue....
[12:10] <joey> there was a file name that included a funny space and two periods.
[12:10] <joey> I changed that and am attempting to push again
[12:13] <lifeless> where was the file
[12:13] <lifeless> jml: does the lp server capture server side errors to oops yet?
[12:13] <jml> lifeless, no.
[12:13] <lifeless> or to some log we can see - i want the server side backtrace
[12:16] <spiv> joey: filenames really should not have that effect on the network protocol
[12:16] <spiv> (will be in bed soon, really!)
[12:16] <joey> spiv: I'll give it a shot.
[12:17] <spiv> joey: so I very much doubt that is the issue, it just doesn't fit with symptoms so far at all
[12:17] <joey> oh you know, maybe I should have done a -Dhpss
[12:17] <jml> lifeless, whatever logs we have are synced to devpad -- I doubt the server-side backtrace is synced though. a losa will be able to point you at the right directories, and might be able to sync the appropriate ~/.bzr.log on request.
[12:18] <lifeless> jml: well, its 2317; I'm beat
[12:18] <jml> lifeless, ok. thanks for trying.
[12:18] <lifeless> this needs to be gathered to move this further I suspect
[12:19] <lifeless> joey: if you want to track down the log for the error, so we can look at it when .au rolls around (or so vila can look at it), that would be great.
[12:19] <lifeless> joey: the error you see is local bzr saying 'the server spat at me. waaah.'
[12:19] <lifeless> joey: there is a real backtrace on the server somewhere.
[12:20] <spiv> joey: yes, -Dhpss -Dhpssdetail, please
[12:20] <joey> lifeless: I was hoping that was the case :-)  Just wondering if I can translate the "waahh" into something that might help me diag the problem
[12:21] <spiv> joey: the server-side traceback is what we really need, but -Dhpss -Dhpssdetail on the client might provide some useful clues
[12:24] <lifeless> joey: talk to a losa; they can flail about more effectively.
[12:24] <lifeless> :)
[12:24] <joey> thanks spiv... and lifeless ... I'll wait to this one finishes or crashes to prove my theory and if it abends I'll try the debug items
[12:25] <joey> heh. Maybe herb or mthaddon can find something for me
[12:57] <joey> spiv: lifeless - the filename rename did the trick
[12:57]  * joey updates the bug
[13:00] <Peng> It did? But...why?
[13:00] <Peng> o_O
[13:00] <spiv> joey: I *really* doubt that is more than a co-incidence
[14:56] <jam> morning all
[15:05] <jam> evening igc
[15:05] <rubbs> morning
[15:05] <igc> hi jam
[15:06] <jam> igc: other than needing to go to bed, how are things going?
[15:07] <igc> I'm fighting windows installers tonight
[15:07] <igc> debugging me new scripts
[15:17] <igc> jam: any chance you can upload one of the installers I built to people.canonical.com say?
[15:17] <igc> jam: I'm heading to bed now but I'd like to test it on the weekend
[15:17] <jam> k
[15:17] <igc> it's the one tagged igc
[15:17] <igc> jam: ^
[15:17] <igc> jam:thanks
[15:18] <jam> on d?
[15:42] <NfNitLoop> hrmm.
[15:43] <NfNitLoop> what would cause a commit back to svn to have the property bzr:pointless?
[15:43] <NfNitLoop> It seems to be doing those commits to store some sort of metadata in the commit properties, but I only have 2 revisions in my local repo to push.
[15:43] <jelmer> NfNitLoop: a commit that is pure administrative
[15:44] <jelmer> NfNitLoop: i.e. shouldn't appear in "bzr log" but is required because of the way svn works
[15:44] <Tak> does bzr have any special provision to handle the situation where a branch contains large, binary files that often change?
[15:44] <NfNitLoop> required for what reason?
[15:45] <NfNitLoop> Tak:  It'll diff binary files just like text files.... no special provisions, AFAIK.
[15:47] <NfNitLoop> jelmer: I mean, I see why you might need that.  I'm just wondering what the common case for it would be.
[15:47] <NfNitLoop> (My 2 revisions seem pretty straightforward, not sure why I'm seeing this behavior for the first time today.)
[15:50] <NfNitLoop> I did do a rebase before pushing back to SVN.
[15:50] <NfNitLoop> but I don't know why that should matter.
[15:53] <Tak> hm - I ask because I went to branch from an svn repo (where that happens), and I was around a gig downloaded at ~200/~18000 revisions in, and the tip wc size is substantially less than a gig
[15:53] <jelmer> NfNitLoop: IIRC if you push a branch that adds a tag while there is no 'tags' directory and bzr-svn creates the tags directory for you it'll set that revprop
[15:57] <NfNitLoop> hrmm, nope.   it doesn't appear to have changed anything other than that property.
[16:02] <NfNitLoop> Tak: Well, it does keep all of your history.
[16:03] <NfNitLoop> Tak: you might consider a stacked branch next time you do a checkout.
[16:03] <NfNitLoop> that'll download just enough history to recontruct a working copy.
[16:06] <NfNitLoop> jelmer: aah.  It looks like my coworker updated a branch in the /tags directory.
[16:07] <NfNitLoop> and for some reason those commit messages got copied into the branch from which that tag was created.
[16:07] <NfNitLoop> which is wrong, because those changes weren't committed there.
[16:09] <NfNitLoop> (Yes.  It's a complete misuse of the "tags" directory.  But in my experience, it is not uncommon in SVN usage.)
[16:38] <vila> jam: ping
[16:39] <bialix> is it possible to mark command-line option as deprecated?
[16:39] <bialix> there is hidden flag
[16:39] <bialix> I want to make some options hidden and deprecated
[16:39] <bialix> does bzr has some support for this?
[16:40] <jam> hi vila
[16:40] <vila> bialix: no idea :-/
[16:41] <vila> jam: I'm searching how to find back a file-id for a file that has been deleted in a working tree
[16:41] <jelmer> bialix: yeah, I think you can add hidden=True to Option()'s constructor
[16:41] <bialix> I'm not very good in optparse, what method is called when option processed?
[16:41] <jam> vila: you have to walk history until you find a revision where it existed
[16:41] <bialix> jelmer: yes, hidden=True works fine
[16:42] <bialix> I want to make some deprecation check now is some universal manner
[16:42] <jelmer> bialix: I don't think we have a deprecated=True flag, but I guess you could warn the user if you see they use that flag
[16:42] <vila> jam: what is the purpose of has_or_had_id (slightly related) ?
[16:42] <bialix> hmm, Option constructor has custom_callback
[16:43] <jam> vila: I think that only checks the WT before commt
[16:43] <bialix> I think I need to provide my callback with deprecation warning
[16:43]  * bialix trying
[16:43] <jam> so if you delete a file, you 'had' the file, referenced by the existing file_id
[16:43] <jam> once you commit, that will return nothing
[16:43] <jam> I think
[16:44] <vila> :-/ Yeah, my wt is just in that state, the file *is* deleted by the merge but was present in a least one of the parents
[16:44] <jam> vila: well, it is easy enough to just probe all parents with path2id
[16:44] <jam> if it was deleted in the merge
[16:45] <jam> then doesn't it have to be present in the basis (left-hand parent)?
[16:45] <jam> otherwise it would have been deleted already
[16:46] <vila> yes, but I don't have that info anymore when starting from the conflict object
[16:46] <vila> but " probe all parents with path2id" should be enough
[16:46] <jam> it isn't great, but I think it will work for what you need
[16:46] <jam> though...
[16:47] <jam> could you have a conflict if the file was deleted in all parents but had been locally versioned (not yet committed)?
[16:47] <vila> jam: no worries, I plan to need that only for conflicts created *before* I fix bug #531967
[16:47] <jam> bzr add new-file; bzr merge ../other # conflict with 2 files wanting to be 'new-file'
[16:48] <vila> bzr add-new file should create a new file-id so I think it's a different case, let me think
[16:49] <bialix> custom callback working fine
[16:49] <jam> vila: sure, it just is a potential to cause a conflict
[16:49] <jam> another way is just
[16:49] <jam> touch new-file
[16:49] <jam> bzr merge ../adds-new-file
[16:49] <vila> jam: I think that will be a DuplicateEntry conflict which can have two file-id involved
[16:49] <jam> well, --force
[16:50] <jam> vila: I trust that you know better than me, I'm just trying to bring up edge cases
[16:50] <vila> jam: thanks for that
[16:50]  * vila notes to add tests for just to be safe ;)
[16:52] <vila> jam: (Pdb) pp tree.revision_tree('other').path2id('new-dir')
[16:52] <vila> 'dir-id'
[16:52] <vila> \o/
[17:24] <vila> jam: (teddy bear) Can you think of a *simple* way to restore an inventory entry as it was in an available revtree ? This has to cope with the entry being of any kind of course
[17:26] <jam> vila: you mean like 'bzr revert' sort of thing?
[17:27] <jam> I'm not really sure what you mean by 'restore'
[17:27] <jam> are you trying to do something on disk? only in the inventory, etc?
[17:27] <jam> and I assume this is in a WT?
[17:27] <vila> then entry doesn't exist in my current wt, I want to add one from a revtree
[17:27] <jam> vila: the only stable way I can think of is to use 'revert(specific_files)'
[17:28] <jam> I don't think it is particularly simple
[17:28] <vila> jam: yeah, I thought so :-/
[17:28] <jam>         _mod_merge.transform_tree(tree, tree.basis_tree(), interesting_ids)
[17:28] <jam> is what "bzr remerge" uses
[17:28] <jam> before it re-applies the merge
[17:29] <vila> I'll punt then and abort in that case, it should be rare enough to not be really that important
[17:29] <jam> so transform 'tree' into 'other_tree' for objects mentioned in 'interesting_ids'
[17:29] <jam> vila: it is a single line of code :)
[17:29] <vila> haaa, *that* sounds what I'm after
[17:40] <bigjools> hi - I just had bzr traceback when I was merging a bundle: http://pastebin.ubuntu.com/389096/
[17:55] <vila> jam: bah, that doesn't work, long story short, I need my fix first which sucks because it means my tests won't be failing anymore which in turn means I won't be able to test my backup plan 8-{
[18:05] <vila> jam: using tree.revert([revtree,id2path(file_id)], etc) seem to work better ! \o_
[18:07] <jam> vila: the only concern there is that I *think* 'tree.revert(dir-id)' will revert all files underneath it?
[18:08] <vila> jam: At that point, the directory *should* be empty (at least I hope so :)
[18:08] <vila> It doesn't exist anymore so I just need to recreate it, I'm pretty it's empty,
[18:09] <vila> for dirs that is, for files and symlinks... well, that doesn't apply ;-)
[18:14] <jam> vila: but wouldn't it end up restoring the files that used to be in the directory in that parent?
[18:14] <jam> (not sure, but def something to test)
[18:14] <vila> jam: I sure will, but AIUI, the conflict can't be created if the dir is not empty (that's what I need to check)
[18:15] <awilkins> Is an "inconsistent delta" error as critical as it sounds in #256409
[18:17]  * vila EODing
[18:17] <vila> bye all !
[18:18] <vila> jam: thanks for help and the teddy bearing ;-)
[18:29] <jam> awilkins: there is a known form where 'bzr commit' and a deleted nested directory (deleting a/ and a/b/ and a/b/c), which commits fine, but fails at one point, and you need to run 'bzr update' afterwards
[18:30] <jam> there it isn't serious
[18:30] <jam> just a bug in handling recursive removal
[18:30] <jam> otherwise, prob serious
[18:32] <awilkins> jam: The scenario is as follows... this branch was pulled from an SVN repo. The lead developer has had a moment of confusion (doesn't seem to understand version control) and copied a folder from an old revision forwards in time as an attempt at renaming it.
[18:33] <jam> awilkins: well, that sounds like a bzr-svn issue, as it could be supplying an invalid delta to the rest of the code
[18:33] <jelmer> awilkins: bzr-svn should be able to handle that
[18:33] <awilkins> jam: It's happening during a bzr mv --auto
[18:33] <jelmer> awilkins: this is a change that's already been committed?
[18:34] <awilkins> jelmer, They must be because I'm working in a fresh checkout of a past revision
[18:34] <jelmer> awilkins: how do you know it happened during a bzr mv --auto ?
[18:35] <awilkins> jelmer, The error was raised during bzr mv --auto ; I don't know when the root cause of the error arose
[18:35] <awilkins> I'm trying to create a revision that's this persons changes done right... then I can merge the changes from everyone else which he's ignored because he's not committed for a few weeks
[18:36] <jam> awilkins: hmm.. I've seen that with stuff trying to be renamed into a dir that wasn't versioned
[18:36] <jam> again, a bug, but shouldn't long-term break anything
[18:36] <jam> the error is to prevent getting corruption
[18:36] <jam> so getting it during 'bzr mv' is probably ~ok, getting it during 'bzr commit' is more worrisom
[18:36] <awilkins> jam: Yes, eventually it stops throwing the error if you manually add a bunch of parent folders
[18:36] <awilkins> Alas, mv --auto is guessing too promiscuously
[18:37] <awilkins> I guess it's not so hot at Java code with enormously similar and long import lists
[18:57] <jam> awilkins: IIRC if a line is very common, it gets less weight for matching
[18:57] <jam> however, if you are saying they shouldn't match at all, there is probably a 50% threshold or so
[19:41] <cr3> how can I use bzr to patch a branch from revision x..y in a different branch, which happens to not have the same root
[19:42] <cr3> hm, seems to be as simple as bzr merge -rx..y /path/to/other/branch
[19:42] <cr3> awesome! 167 conflicts encountered.
[20:08] <jam> cr3: bzr diff -r x..y /path/to/other/branch | bzr patch ?
[20:47]  * cody-somerville is very happy bzr now handles merging local commits on a binded branch correctly. :)
[22:24] <mrjazzcat> hey.  newbie bzr dev question.  I'd like to setup a simple bzr server that I build to test remote calls.  Is ssh the best model to pick?  If so, how to I tell the client which bzr program to invoke.
[22:25] <lifeless> what do you mean?
[22:25] <lifeless> I don't know what 'build to test calls'
[22:25] <mrjazzcat> well, I've built bzr 2.2 and I want to run it as the server when I run the client.  But, what gets run via sftp (for instance) isn't up to me.
[22:26] <lifeless> when pushing over sftp, the server is just sftp - no bzr code runs at all
[22:27] <lifeless> bzr only runs in client-server mode when you push to a bzr://, bzr+ssh://, or http:// [when the WSGI interface is enabled on the server]
[22:28] <mrjazzcat> ah, I see (sort of).  I thought that sftp could be used as the simplest server.  You're saying that all the commands to run come from the client, in that case.
[22:29] <lifeless> with SFTP, bzr works just like it does on local disk - sftp only offers a virtual file system
[22:29] <lifeless> no RPCs
[22:29] <mrjazzcat> ok, thanks.  That makes sense.
[22:30] <lifeless> with bzr+ssh you can export BZR_REMOTE_PATH to control the program invoked on the remote host
[22:30] <lifeless> bzr help env-variables
[22:32] <mrjazzcat> thanks.  That's better.  That's what I'll do.  I'm trying to pick off an easy bug to get started, and I thought figuring out the client-server model was also a good place to start
[22:34] <lifeless> many easy bugs are tagged 'easy' in the bugtracker
[22:34] <lifeless> that may help you find a good bug
[22:36] <mrjazzcat> thanks, it will
[22:54] <neaj> hi all .. what is submit_branch in .bzr/branch/branch.conf ?
[22:55] <lifeless> its the branch that 'bzr submit' will submit to by default
[22:56] <NfNitLoop> is that an addon?   'bzr help submit' is an error for me.
[22:57] <NfNitLoop> and yet I've got a submit branch.
[22:57] <NfNitLoop> (error: unknown command "submit")
[22:57] <lifeless> sorry, 'send'
[22:57] <lifeless> bzr send
[22:57] <NfNitLoop> I think it's the default branch for merge too?
[23:01] <neaj> i'm not really clear on the differences between parent_location submit_branch push_location
[23:02] <neaj> i don't know why my submit branch is different from my push location
[23:02] <lifeless> zr help configuration
[23:02] <neaj> and why isn't it a push branch?
[23:04] <jpds> neaj: I think submit branch is the tweak branch which your branch will be merged into.
[23:05] <neaj> i've never used 'send'. i merged from another repo. that repo ended up as submit branch. don't understand the reasoning behind that yet
[23:06] <neaj> jpds: in this particular case, the submit branch is pointing at a throwaway branch that i just used to migrate an svn repo into my bzr repo
[23:07] <neaj> now i've moved the throwaway branch out of the way, but it bothers me that i now have an invalid submit_branch in .bzr/branch/branch.conf
[23:07] <lifeless> so delete it
[23:08] <neaj> lifeless: my point is that i don't want to end up with funny invalid things that i have to fiddle by hand just by working normally
[23:09] <NfNitLoop> all it's doing is remembering the last place you did an operation from so that it becomes an optional parameter.
[23:09] <NfNitLoop> just specify your destination every time and it won't affect you.
[23:09] <NfNitLoop> I never quite grokked submit_branch either.
[23:09] <NfNitLoop> but I always specify where to merge from so it doesn't mater much.
[23:10] <NfNitLoop> I sortof want to write a plugin to just create a named pool of all branches that a branch has seen and prompt on every operation.
[23:10] <NfNitLoop> but... yeah, that hasn't happened yet. :p
[23:11] <lifeless> NfNitLoop: bookmarks can do something in that direction
[23:11] <lifeless> NfNitLoop: could extend it
[23:12] <lifeless> neaj: so, bzr remembers things you work with, the first time; you deleted the branch it had remembered - I don't see that there is an easy way to avoid that.
[23:12] <lifeless> neaj: you don't need to manually fiddle by hand - the next time you do a send, just do '--remember', and bzr will update the setting.
[23:13] <neaj> that name (submit branch) feels super confusing to me. it sounds very familiar, but turns out it doesn't have to do with commit or push, but with send. send turns out to be an async version of push, but it follows different rules as to where the changes will go.
[23:14] <lifeless> neaj: send is not an async version of push
[23:14] <neaj> no?
[23:14] <lifeless> neaj: send is for sending your changes to someone else to integrate. They might merge. They might pull.
[23:14] <neaj> i appreciate everyone's teachings, by the way :-]
[23:14] <lifeless> push updates a remote branch to be a mirror of your local branch.
[23:14] <lifeless> very different
[23:15] <neaj> OK, so push puts your changes into a branch, and send sends your changes to someone who may or may not put them into a branch
[23:16] <neaj> and send assumes you'd want to send to wherever you last merged from.
[23:16] <neaj> if i understand correctly ..
[23:17] <lifeless> by default, yes
[23:17] <lifeless> because, common case, you are merging from the maintainer
[23:17] <lifeless> and sending back to the maintainer
[23:17] <lifeless> and pushing to your own repository
[23:21] <neaj> OK, i see.
[23:21] <neaj> hmm, i notice that 'bzr info' talks about push/parent/submit *branch*, but 'bzr help configuration' talks about submit_branch, push_location and parent_location
[23:22] <neaj> i wonder if 'send branch' would be a better name for 'submit branch'. send bransh for sending, push branch for pushing.
[23:23] <mkanat> neaj: It's also the bundle branch.
[23:24] <neaj> you send bundles also, right?
[23:24] <mkanat> I never do, personally. :-)
[23:25] <neaj> i mean that's how they reach that branch
[23:25] <mkanat> They can be merged in.
[23:28] <neaj> in that case i wonder if 'send' should be called 'submit'
[23:29] <lifeless> it was originally
[23:30] <lifeless> it got renamed for few reasons; the setting stayed the same for compatability
[23:39] <jelmer> lifeless: btw, I started on adding support for adding 'bugs' revprops in the commitfromnews plugins
[23:39] <neaj> hehe .. names are tricky ..
[23:39] <lifeless> awesome
[23:39] <jelmer> unfortunately the commit message template hook doesn't seem to allow modification of the commit message
[23:39] <jelmer> so I'll have to use a different hook I guess
[23:40] <jelmer> (lp:~jelmer/bzr-commitfromnews/extractbugnumbers)
[23:43] <lifeless> jelmer: do you mean 'of the commit object' ?
[23:43] <jelmer> lifeless: yes, sorry
[23:43] <lifeless> jelmer: I think we'll want a new hook anyway, because we want to process the /saved/ commit message, not the generated template for bug numbers.
[23:50] <jelmer> lifeless: do we? I don't want the bug numbers to show up in the commmit message itself, but stripping them out afterwards is hard.
[23:54] <lifeless> jelmer: oh, I want them to stay in the message.
[23:54] <lifeless> I hadn't really thought about hiding them.
[23:58] <jelmer> Generally I would have something like "(Jelmer Vernooij, #34243242)" after each line in the NEWS file. That seems like redundant information to have in the commit message.