[00:34] <TimoJJ> I am looking for a good examples of use for Bzr in Web Site developing.  I read the many doc but so much!  I look for ideas of central server that holds Production and Development repositores. And then I am checking out at my laptop somewhere else for Development then pushing to Production at central again.
[00:35] <TimoJJ> I am so much confused with to use branches or checkouts.  Good examples are nice!
[00:35] <TimoJJ> Can you help if you have time?
[00:35] <poolie> TimoJJ: maybe http://beuno.com.ar/archives/80
[00:36] <poolie> or http://wiki.bazaar.canonical.com/BazaarUploadForWebDev
[00:38] <TimoJJ> poolie: I read the second before but it also added trees.  I dont know if or no to use trees in central server.  It was more advanced right then than me.  I am looking to the other reference now also.
[00:40] <TimoJJ> poolie: These is intersting but I start in the other direction.  WIth every thing first on the central server then to check out at remote.  Is this still good for me?
[00:40] <igc> morning
[00:42] <poolie> TimoJJ: is the central server an actual web server where you want to deploy your stuff, or just a place to hold your bzr branches?
[00:42] <poolie> igc, hi!
[00:43] <igc> hi poolie!
[00:44] <jrib> TimoJJ: http://wiki.bazaar.canonical.com/BazaarForWebDevs too
[00:45] <TimoJJ> poolie: It is both things.  On the Central server I think to have /path/DirA as the Master branch that will publish on web server to public.  Then I want to work developing only at a different branch or maybe chekcout that will publish on web server only to me privatly.
[00:46] <TimoJJ> When I am happy with the private web project apparance then to push the changes to the Master branch again for the public to see.
[00:51] <jam> hi igc
[00:51] <igc> hi jam! Back from leave now?
[00:52] <jam> poolie: I just sent you an email with some of the details about the 'denormalization' stuff I was talking about. It would be nice if you could give it a look over
[00:52] <jam> igc: technically back last week, but not particularly high-availability :)
[00:52] <TimoJJ> jrib Thanks you also.  Yet the URL is for the laptop first then the server but I can make it back ways too.
[00:54] <poolie> TimoJJ: in that case you do need a tree on the server for the version exposed to the public
[00:56] <TimoJJ> poolie: So it is not to expose to the public the Master branch but a checkout of it?  The checkout is in the tree then, yes?
[00:59] <poolie> so one setup you could have is
[00:59] <poolie> a repository on the server with all your branches
[00:59] <poolie> jam: o
[00:59] <poolie> jam: ok
[00:59] <poolie> and then a separate checkout of the production branch, with a cron job to update it every hour or so
[01:05] <Peng> jam: <3
[01:06] <Peng> Loggerhead currently supports pretty old versions of bzr. Back to 1.13, IIRC. I personally don't really mind dropping <2.0 in the next release, but I always run bleeding-edge stuff anyway.
[01:07] <Peng> Plus, this is probably worth it anyway. :-\
[01:08] <Peng> beuno: Noo, I'd be a terrible maintainer. jam touched the code last, let's make him do it. :P
[01:09] <Peng> Anyway I was AFK...
[01:09]  * Peng goes back to that
[01:19] <lifeless> Peng: so tht was a 'yes' then ?
[01:45] <GungaDin> How long does bzr patch usually take to patch about 5  files?
[01:45] <GungaDin> sorry for the weird question... but for me it takes AGES!
[01:46] <lifeless> instant, I'd expect
[01:46] <lifeless> unless the files are big (megabytes)
[01:46] <lifeless> or perhaps you have a lightweight checkout of a network branch or something
[01:47] <GungaDin> no, they're just regular txt files. nothing too big.
[01:47] <Peng> lifeless: What did I just agree to?
[01:52] <lifeless> maintaining loggerhead?
[01:57] <GungaDin> my bzr on another machine doesn't recognize the command 'patch'
[01:57] <GungaDin> is it in bzrtools?
[01:57] <poolie> could be, 'bzr help patch' will tell you
[02:22] <GungaDin> how am I supposed to create the diff file to? if I want directory A to change into directory B?
[02:28] <lifeless> what do you mean
[02:36]  * igc out for a few hours
[02:47] <GungaDin> I tried to create one with diff -crB but when I try to patch --dry-run I get an error saying it can't find the file to patch (and it exists!).. so I'm doing something wrong.
[03:00] <mwhudson> is the news_merge plugin bundled with bzr
[03:00] <mwhudson> ?
[03:00] <poolie> yes, in 2.2
[03:01] <mwhudson> i guess we should be looking at upgrading lp to the 2.2 series
[03:24] <bignose> I've branched from an upstream Git repository. can I generate changesets that, when upstream adds them to their repository, will be recognised by Bazaar as the same changes I made?
[03:25] <lifeless> thats 'round tripping', and no, its not supported for bzr-git yet.
[03:25] <lifeless> however, bzr handles duplicate changes pretty well, most of the time - so it may not matter.
[03:29] <bignose> okay. is it supported for any of the foreign VCSen?
[03:30] <lifeless> bzr-svn
[03:32] <bignose> do I require commit access to upstream's Subversion repository for successful round-trip changesets?
[03:32] <bignose> or can I generate changesets that upstream can incorporate for themselves that will be round-trip changesets?
[03:32] <NfNitLoop> bignose: you'd need to be able to push your own changes for svn round-tripping.
[03:32] <lifeless> commit access, for bzr-svn
[03:33] <lifeless> I suspect git round triping, when it happens, won't require that.
[03:51] <poolie> hello bignose, lifeless, NfNitLoop
[03:52] <thumper> I wish I could go `bzr merge -i :next some/file` in a pipeline
[03:53] <NfNitLoop> poolie: H'lo!
[03:59] <bendj> Can bzr-explorer initiate/open a bzr+ssh URL?  I can easily do it from cmd line, and then have explorer 'explore' the local store ... but simply not clear how/where to specify the bzr+ssh connection IN bzr-explorer GUI.  Is it right in front of my nose, and I'm missing it?
[03:59] <poolie> Open/Location i think
[04:04] <bendj> poolie Yup, thanks.  NOT in the 'get source from elsewhere' tab.  sigh.
[04:10] <poolie> lifeless/jam: what do you think of https://bugs.edge.launchpad.net/bzr/+bug/551391
[04:11] <lifeless> poolie: from the one liner it sounds interesting if it works
[04:11] <lifeless> thumper: try :next/some/file
[04:11] <thumper> lifeless: ah, thanks will try
[04:11] <poolie> mm, i think i don't have a good enough idea what data realistically helps
[04:28] <lifeless> poolie: if it got a meliae dump we can figure out what matters later
[04:29] <lifeless> but they are big
[04:29] <poolie> yes, and also we're not likely to have it in every case
[04:53] <Peng> jam: ping
[04:55] <jam> Peng: what's up?
[04:55] <Peng> jam: Hi. :D
[04:56] <Peng> jam: Wanted to ask you about Loggerhead, known_graph and statictuples.
[04:57] <Peng> Basically, I run my statictuples branch on my server, I'd like to try merging known_graph, and I was wondering what I should do about the conflicts. :D
[04:57] <Peng> I'm not sure if I had a more specific question formed when I pinged you. :P
[04:57] <Peng> jam: You wrote in a comment that you tried using StaticTuples in it. Do you still have the code? :D
[04:58] <jam> well if you have a conflict, clearly you should revert to my code :)
[04:58] <jam> I didn't to ST everywhere, but certainly inside that func
[04:59] <Peng> I had stuck compute_whole_history_data full of StaticTuples, and you rewrote the whole thing, so it conflicts everywhere. :D
[04:59] <Peng> Well, not all of it, but...
[05:00] <jam> rev 409 has some ST stuff, I think, though that might have just been the timing comments
[05:01] <jam> i can  redo it if you want
[05:01] <Peng> It doesn't have any code.
[05:01] <jam> it wasn't very hard
[05:02]  * Peng shrugs.
[05:02] <Peng> On the one hand, I'm selfish and don't want to do work. On the other hand, I also feel that's immoral. :P
[05:05] <Peng> Also -- that "What about ghosts?" comment sounds ominous. Is it likely to explode?
[05:08] <jam> Peng: http://paste.ubuntu.com/406331/
[05:09] <Peng> Oh. Thank you. <3
[05:09] <jam> I didn't explicitly test it, but the KGmerge_sort code knows how to handle ghosts
[05:10] <jam> *without* having to stirp them
[05:12] <jam> strip
[05:21] <Peng> I just pushed it to https://code.edge.launchpad.net/~mnordhoff/loggerhead/statictuples_and_known_graph fwiw
[05:27] <Peng> Trying it out, it hasn't died yet. \o/
[05:33] <spm> Peng: is that a challenge for me to break it on you? no reason for asking.... >:)
[05:34] <Peng> spm: Go ahead. :)
[05:34] <Peng> It's running on http://bzr.mattnordhoff.com/loggerhead/ too
[05:34] <spm> woo!
[05:37] <lifeless> EODing
[05:38] <Peng> lifeless: See ya. :)
[05:43] <Peng> spm: BTW, the most important branch to break is lp:~jameinel/loggerhead/known_graph. The StaticTuple stuff probably isn't going to be merged any time soon anyway, so it doesn't matter as much.
[05:44]  * spm has stepped into an alternate universe where users encourage bofhs to break their work. this is wrong. WRONG i tell you!!! it's like cows pointing out which part of their anatomy is tye best to eat!
[05:45] <lifeless> spm: oh, you saw that simpsons episode?
[05:45] <spm> lifeless: was thinking hitchhikers GTTG?
[05:46] <Peng> Hey, if you don't kick the tires now, it'll fall over when it eventually gets deployed to Launchpad/
[05:46] <spm> Peng 1, spm 0
[05:50] <bendj> When creating a *shared* repo, containing multiple branches etc, is there just *one* .bzrignore file at the top level of the repo that applies to all contained branches?  or does/can each branch have its own .bzrignore?
[05:50] <Peng> .bzrignore is a branch thing.
[05:50] <Peng> Shared repos are simply a storage and performance optimization.
[05:54] <bendj> Peng Ah, so every branch gets a .bzrignore, if needed.  Do I need to include ".bzrignore" *IN* .bzrignore, or does it knwo to ignore itself?
[09:20]  * igc dinner
[12:13] <nlisgo> is there any way to get bzr to create a diff file that contains differences in binary files too?
[12:13] <nlisgo> not saying I'm going to use it, but is it possible?
[12:19] <maxb> The diff format itself has no way of representing binary files
[12:21] <Peng> Although there is git's extension.
[12:22] <Peng> nlisgo: Why? You can use "bzr send" to create a file that bundles revision data, including a diff for text files. (Binary files are just encoded in the base64 chunk at the end.)
[12:25] <nlisgo> peng: I'm working on a site that is versioned by svn. They didn't give me access to the repo but just provided me with the site files. I've versioned with bzr for my development and now want to create a patch file that can put everything in place for them
[12:25] <nlisgo> peng: can send create a patch file that can be applied using the patch command?
[12:26] <Peng> nlisgo: Probably, but mostly it's intended for bzr. Certainly nothing else supports the binary part.
[12:26] <nlisgo> bzr diff allows me to create a batch file from revision 2 to the present version. How do I do this with a send file
[12:26] <Peng> Um. Convince them to use bzr-svn? :D
[12:26] <Peng> Although if *you* didn't use bzr-svn it would still be a huge pain.
[12:27] <nlisgo> I think for ease in this instance I'm going to give them a diff genrated patch file and then just zip up the image folder
[12:27] <Peng> That sounds like a good idea.
[12:27] <nlisgo> just wanted to ask the question
[12:27] <nlisgo> bzr gets funny if file names contain a single quote
[12:28] <Peng> I doubt it.
[12:29] <Peng> Creating a file called ' works fine for me.
[12:29] <nlisgo> I tried to version a site the other day and it churned out an error when it reached so files that had been uploaded with single quotes in the filename
[12:29] <nlisgo> when I tried to commit those files to the repo
[12:30] <Peng> What kind of error?
[12:30] <Peng> Um.
[12:30] <Peng> Scratch that. What was the error message?
[12:30] <Peng> Perhaps you weren't escaping shell args properly or something.
[12:30] <Peng> Oh... Is this on Windows?
[12:30] <nlisgo> on linux
[12:31] <nlisgo> i'll try and recreate the problem again because I just deleted the files because they weren't being used
[12:31] <Peng> Ah.
[12:31] <nlisgo> i'll be back in a few minutes
[12:31] <Peng> Linux should really be fine. Bazaar doesn't do anything to arguments and the kernel and file systems aren't stupid.
[12:38] <nlisgo> couldn't recreate problem on my local machine but it might have been to do with the tree that is used when a bzr repo is initialised on the server
[12:39] <nlisgo> i'll try again later on the server
[12:39] <nlisgo> thanks for your help peng
[12:49] <Lo-lan-do> G'day all
[12:53] <Lo-lan-do> Is there a working email-on-commit plugin that I can install on a remote server?
[12:56] <Peng> nlisgo: When pushing to a server, Bazaar doesn't create a working tree. It doesn't use any unusual characters at all.
[13:09] <nlisgo> well, if I see the problem again I'll come back with the error
[13:47] <mgedmin> waaaah! either bzr or launchpad is being nasty to me
[13:47] <mgedmin> a while ago I did bzr branch lp:zodbbrowser
[13:47] <mgedmin> now I can't push back to launchpad
[13:48] <mgedmin> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~zodbbrowser-dev/zodbbrowser/trunk/.bzr/)
[13:48] <mgedmin> is not compatible with
[13:48] <mgedmin> CHKInventoryRepository('file:///home/mg/bzr/zodbbrowser/.bzr/repository/')
[13:48] <mgedmin> different rich-root support
[13:48] <mgedmin> sorry for the paste
[13:48] <Peng> Uh-huh.
[13:48] <mgedmin> actually, this appears to be a bound branch (aka checkout), so turns out I don't need to push
[13:48] <mgedmin> but the error message is ... confusing, to say the least
[13:49] <Peng> It's a pretty straightforward error message, just not very...explanatory.
[13:49] <mgedmin> wait, it's a lightweight checkout of a branch in my home directoryu
[13:49] <mgedmin> I was following the instructions at http://wiki.bazaar.canonical.com/GitStyleBranches
[13:49] <mgedmin> bazaar, you're not winning any friends this way
[13:50] <mgedmin> what do I do now?
[13:50] <Peng> mgedmin: Either create a non-rich-root repo and redo your revisions somehow, or get lp:~zodbbrowser-dev/zodbbrowser/trunk to upgrade to a rich-root format.
[13:52] <mgedmin> I hate people who go to a project's channel and say "you're crap, I'm switching to $ALTERNATIVE"
[13:52] <mgedmin> but now I deeply understand that urge
[13:53] <Peng> One day everyone will be on rich-root formats and this won't bite anyone anymore. Until then...yeah. :-\
[13:55] <SamB_XP> Peng: what, who's not on rich-root yet?
[13:55] <SamB_XP> I need to go byte them!
[13:55] <Peng> SamB_XP: lp:~zodbbrowser-dev/zodbbrowser/trunk apparently
[13:55] <SamB_XP> zodbbrowser, switch, if you value your neck!
[13:55] <mgedmin> I don't suppose mere mortals can upgrade repositories stored on launchpad?
[13:56]  * mgedmin tries bzr upgrade lp:zodbbrowser
[13:56] <mgedmin> wow, it's doing something
[13:56] <mgedmin> ... very slowly ...
[13:56] <SamB_XP> sure they can, if they've write access
[13:56] <Peng> mgedmin: You're in ~zodbbrowser-dev?
[13:56]  * mgedmin is
[13:56] <SamB_XP> but it's probably smarter to just steal them, convert them, and then upload them again
[13:57] <spiv> Isn't there a button in the web UI for upgrading now?
[13:57] <SamB_XP> oh, is there ?
[13:57] <Peng> Oh, right, I've heard something about that.
[13:57] <SamB_XP> who would have delayed-computation (er, that is, thunk) it ?
[13:58] <spiv> Yeah, there is.  Well, a link rather than a button.  .../+upgrade
[13:58] <mgedmin> cool
[13:59] <SamB_XP> hmm ... how come upgrade on a remote smart repo doesn't just ask the server end to do it ?
[13:59] <Peng> The developers are mean?
[13:59] <spiv> SamB_XP: because no-one has written that yet
[13:59] <mgedmin> because it's fun to have people wait at 10 kB/s
[14:00] <mgedmin> upgraded!
[14:00] <SamB_XP> spiv: good answer
[14:00] <SamB_XP> well, I mean, tolerable
[14:00] <spiv> SamB_XP: the most immediate problem is that there's not really any infrastructure for streaming progress info via the smart protocol yet
[14:00] <mgedmin> thank you, Peng and SamB_XP!
[14:01] <SamB_XP> spiv: ah, that *would* be an issue
[14:01] <mgedmin> I had no idea I could/had to upgrade repositories hosted on launchpad by myself
[14:01] <spiv> SamB_XP: the current version of the protocol supports streaming info
[14:01] <SamB_XP> mgedmin: what'd I do ?
[14:01] <mgedmin> SamB_XP, said "zodbbrowser, switch, if you value your neck!"
[14:01] <SamB_XP> lol
[14:01] <spiv> SamB_XP: just no-one has taken the time to figure out what streaming progress should look like for bzrlib (although subunit is probably a good place to look for inspiration if you're interested...)
[14:01] <mgedmin> which made me try 'bzr upgrade lp:zodbbrowser", which I trully expected to fail with "cannot do that remotely"
[14:02] <SamB_XP> the thing is that bzr is perfectly happy to do remote filesystem access when the "smart" protocol is missing a piece of functionality
[14:03] <spiv> And even some smart remote fetching, in this case, I think, but not as much as it could.
[14:04] <spiv> I'm sure that we'll fix 'bzr upgrade' via smart server before the next major format bump, but at the same time we're also not planning a major format bump any time soon.
[14:05] <spiv> It'd be very nice to fix, but there are plenty of other very nice to fix things I'd probably want to fix first.
[14:05] <spiv> e.g. commit to stacked branch
[14:06] <mgedmin> commit or push?
[14:06] <spiv> Or support resuming interrupted fetches.  Although they are both probably a bit harder, but they'd also be more valuable I think.
[14:06] <mgedmin> a friend was recently complaining that a trivial bugfix to a large repository took ages to bzr push to a new hosted branch
[14:07] <spiv> (especially now that LP has the 'upgrade' link in its UI)
[14:07] <spiv> mgedmin: that's odd
[14:07] <spiv> mgedmin: there aren't any major known issues there
[14:08] <mgedmin> it could be a case of old repository formats
[14:08] <mgedmin> schooltool is not a new project
[14:10] <spiv> Definitely worth upgrading to 2a
[14:12] <spiv> (Also, I have a patch in review that helps one of the minor known issues with pushing via non-smart server: https://code.edge.launchpad.net/~spiv/bzr/smarter-index-search)
[14:13] <spiv> mgedmin: if poor performance persists after upgrading, please ask your friend to file a bug or post to the list about it.
[14:13] <Peng> Hello, jelmer's evil twin. :D
[14:14] <SamB_XP> Peng: it looks like he just changed IP address or somesuch, nothing to be alarmed by!
[14:14] <jelmer> Peng: I thought jelmer was the evil one? :-P
[14:14] <SamB_XP> jelmer: aren't YOU jelmer?
[14:15] <Peng> SamB_XP: That's what he wants you to think!
[14:21] <Lo-lan-do> Is dato still maintaining bzr-hookless-email?  I think I fixed it…
[14:22] <jelmer> Lo-lan-do: I don't think he is
[14:23] <Lo-lan-do> Who should I send the merge request to then?
[14:24] <jelmer> Lo-lan-do: Congratulations on becoming the new bzr-hookless-email maintainer!
[14:25]  * jelmer runs
[14:25]  * Lo-lan-do grumbles
[14:25] <Lo-lan-do> I guess I'll push to somewhere under pkg-bzr in Alioth :-)
[14:26] <jelmer> heh
[14:26] <jelmer> Actually, I think LarstIQ was doing some maintainance work on it recently
[14:26] <jelmer> not sure what happened to that
[14:26] <Peng> He gave up so we wouldn't make him the new maintainer. :D
[14:34] <SamB_XP> Peng: you must be more careful not to remind people of that tradition before they are drafted!
[14:35] <Peng> SamB_XP: I was already victimised today.
[14:43] <vila> morning jam, ping me when you're here
[16:06] <jam> morning vila
[16:59] <Lo-lan-do> branch.revision_history() will only return a linear sequence of revisions, right?  Not a DAG?
[16:59] <Lo-lan-do> (Still working on bzr-hookless-email)
[17:00] <james_w> Lo-lan-do: I'm pretty sure
[17:00] <Lo-lan-do> Okay, thanks
[17:00] <james_w> it's the left-hand history, you need to use branch.repository.get_graph() to look at the DAG
[17:01] <james_w> bear in mind that computing revision_history() involves loading the whole graph and sorting it, so if you care about performance and aren't doing whole-graph things then using the Graph may be better
[17:02] <james_w> sorry, doesn't involve sorting, but does mean loading a potentially large chunk of the data
[17:03] <Lo-lan-do> I'm just trying to understand bzr-hookless-email's logic when dealing with new branches or disappearing tips due to merges.
[17:04] <james_w> ok
[17:05] <Lo-lan-do> Dealing with new branches is okay, I think.
[17:05] <Lo-lan-do> Now for merges, it might make sense to use the graph indeed.
[17:06] <Lo-lan-do> There seems to be a graph.is_ancestor() method, which is good if it does what I hope it does and doesn't walk the left-hand only.
[17:06] <GaLiLe0> How does this work with or without Eclipse or VS? If there are merely plugins for these does it work without them?
[17:07] <GaLiLe0> In other words do you have to interface it with an IDE?
[17:07] <GaLiLe0> Or does it simply back up the files from the file system itself?
[17:07] <Lo-lan-do> GaLiLe0: What's "it"?
[17:08]  * Lo-lan-do uses Bazaar without an IDE
[17:08] <GaLiLe0> bzr of course
[17:08] <james_w> Lo-lan-do: it is full-history
[17:09] <Lo-lan-do> james_w: Great.  Would you know of a method to find a common ancestor to two revisions?  I can search, but if you know it offhand that's easier :-)
[17:09] <jelmer> Lo-lan-do: Graph.iter_ancestry() ?
[17:09] <jelmer> Lo-lan-do: There's also Graph.find_common_ancestor() I think
[17:09] <GaLiLe0> Lo-lan: without the IDE how do you sync to your repository?
[17:09] <james_w> not offhand, but I would expect something like jelmer suggests
[17:10] <Lo-lan-do> Thanks j*
[17:10] <Lo-lan-do> GaLiLe0: With the Bazaar commands or the Gtk interface or whatever else
[17:11] <GaLiLe0> So the plugins are unnecessary. Is there an advantage to using the plugin?
[17:13] <Lo-lan-do> Some people don't like external tools, and they prefer doing everything from their IDE.
[17:17] <GaLiLe0> it works for source code. word documents etc?
[17:17] <Lo-lan-do> It works for any kind of files, so yes.
[17:18] <Lo-lan-do> It's more efficient on text files than binary files, though.
[17:18] <GaLiLe0> binary files like WORd docs?
[17:18] <Lo-lan-do> Yes
[17:21] <GaLiLe0> do you like the Tortiose interface?
[17:22] <Lo-lan-do> I never tried it myself.
[18:09] <ejat> i got this error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
[19:07] <CoffeeIV> If I have a source tree retrieved from launchpad with "bzr branch lp:whatever" , can I move that directory around and have it still work, or is it's full path hardcoded into itself somewhere ?
[19:08] <Lo-lan-do> You can move it around
[19:08] <Lo-lan-do> I do that all the time :-)
[19:09] <Lo-lan-do> It sometimes gets tricky when you have a local repository because sometimes the references are using relative paths, but for standalone branches it's not a problem.
[19:10] <CoffeeIV> Thanks !
[19:22] <james_w> has anyone ever seen a tag not be sent on push?
[19:22] <james_w> commit; tag; push; with the tag not being visible at the remote end after the push?
[19:28] <james_w> hmm, it's not that
[20:57] <lifeless> moin
[21:04] <cody-somerville> Whats the easiest way to see if a branch is a decedent of some other branch?
[21:05] <james_w> cody-somerville: "bzr missing"?
[21:05] <james_w> bzr missing --mine-only should be empty
[21:05] <james_w> err, hang on, you want to know if they are related, or if they have diverged?
[21:06] <cody-somerville> If they are related
[21:06] <james_w> merge --preview might tell you
[21:09] <phinze_> this should be simple, but i'm at a loss -> "find all commits by a given committer"
[21:10]  * phinze_ needs bzr-search it seems?
[21:10]  * luks recommends bzr qlog if it doesn't have to be a command line
[21:18] <cody-somerville> What branch format do I need to use to have interoperability with 1.13.1?
[21:19] <cody-somerville> (bzr version 1.13.1 that is)
[21:19] <james_w> I think the 1.9 are the most recent supported by 1.13.1
[21:46] <exs> hi
[21:46] <exs> need helü
[21:46] <exs> i have a repo with code. someone had downloaded this repo and changed it. how to merge them together?
[21:46] <exs> but he downloaded without bzr
[21:48] <awilkins> If he downloaded the whole repository, that's still fine
[21:48] <exs> yea
[21:48] <exs> how to merge them together
[21:48] <awilkins> He will need to get the changes to you ; if you don't have common file system access or a shared server, he can send you a merge bundle
[21:48] <exs> he can zip them into a file
[21:48] <exs> then send my the zip file
[21:48] <awilkins> Yes
[21:49] <exs> and i want merge his code with my code
[21:49] <awilkins> Look at `bzr send`
[21:49] <exs> how to do this?
[21:49] <awilkins> Essentially you receive a file and you merge that
[21:49] <awilkins> Bazaar just knows what to do with them
[21:54] <exs> awilkins, can u try to explaim me how to solve the problem
[21:54] <exs> i trying to read the docu but Its difficult to understand
[21:58] <awilkins> Your friend needs to do `bzr send <branch URL>` where the URL is the original branch that you want to merge with
[21:59] <awilkins> His email client will open (if properly configured), or you can dump it to a file
[21:59] <awilkins> You take the file and merge from that as if it was a branch
[22:04] <IslandUsurper> exs, it helps if your friend commits his changes first
[22:05]  * awilkins had assumed this was true when it was said "changed (the repo)" but that's a fair point
[22:06] <jpds>  /1
[22:14] <lifeless> jpds: haha
[22:53] <cody-somerville> hmm... running bzr add results in: bzr: ERROR: exceptions.AttributeError: children
[22:53] <lifeless> cody-somerville: bzr version?
[22:54] <cody-somerville> 2.1.1
[22:54] <lifeless> and the exact command line ?
[22:59] <cody-somerville> bzr add
[23:00] <cody-somerville> lifeless, http://pastebin.ubuntu.com/406738/
[23:01] <cody-somerville> I rmed a symlink and then copied over a directory with the same name.
[23:01] <cody-somerville> remvoing the directory makes bzr add work
[23:03] <cody-somerville> Seems to be bug #341555
[23:05] <cody-somerville> I'll reopen that for you.
[23:08] <lifeless> cody-somerville: 'bzr add', not 'bzr add path' ?
[23:08] <cody-somerville> both throw the exception
[23:08] <lifeless> cody-somerville: please don't reopen fix released bugs
[23:08] <lifeless> open a new bug
[23:08] <cody-somerville> too late :(
[23:09] <cody-somerville> I attached my crash report and everything.
[23:09] <lifeless> ugh
[23:09] <lifeless> its almost certainly different, because we unit test things quite thoroughly
[23:10] <cody-somerville> It looks like maybe the bug just got closed because it was for 1.6.1.
[23:11] <cody-somerville> fyi, it works when if you replace the symlink with a file and not a directory
[23:14] <lifeless> I suspect if you run 'bzr st' first it will work too
[23:17] <AfC> oh dear
[23:17] <AfC> worthil ~/vcs/java-gnome/mainline $ bzr pull
[23:17] <AfC> Using saved parent location: /home/andrew/src/java-gnome/mainline/
[23:17] <AfC> bzr: ERROR: No such file: u'/home/andrew/vcs/java-gnome/.bzr/repository/obsolete_packs/': [Errno 2] No such file or directory: '/home/andrew/vcs/java-gnome/.bzr/repository/obsolete_packs/'
[23:18] <cody-somerville> lifeless, how wonderful. it does!
[23:18] <exs> hi
[23:18] <exs> i need help
[23:18] <exs> i executed bzr uncommit
[23:18] <exs> and he deleted all my new changes
[23:18] <AfC> a second `bzr pull` succeeds
[23:18] <exs> can i undo bzr uncommit?
[23:19] <lifeless> AfC: someone deleted that dir, make it by hand
[23:19] <lifeless> exs: yes, it will have printed instructions when you ran it
[23:19] <lifeless> exs: follow those instructions
[23:19] <exs> these structions are away
[23:20] <AfC> lifeless: fine. Perhaps bzr should just make such a directory on demand? Floating around here for a while now has been "yes it's ok to delete obselete_packs to save Gigs of disk space" so it'll be a common case
[23:21] <exs> lifeless, did he saved something?
[23:46] <mathrick> hey guys, I just pushed a branch over sftp, and it created some files with 600 perms
[23:46] <mathrick> -rw-r--r-- 1 mathrick mathrick   35 2010-03-24 04:44 branch-format
[23:46] <mathrick> errr
[23:46] <mathrick> wait
[23:46]  * mathrick can't read
[23:48] <lifeless> mathrick: that looks like 644 to me :P
[23:48] <mathrick> yes, I know
[23:48] <lifeless> AfC: making the directory is another round trip; we've only ever said its ok to delete the *contents* and then only if you have done sync.
[23:49] <mathrick> I was going off on a bzr: ERROR: Transport error: Server refuses to fulfill the request (403 Forbidden) for http://sei.meidokon.net/repo/thesis/report/.bzr/branch-format
[23:49] <poolie> good morning
[23:49] <mathrick> the client that gives that is 1.15.1
[23:49] <mathrick> poolie: good midnight :)
[23:54] <mathrick> lifeless: so the error is completely bogus, but I can read it fine with 2.1, so I guess it's just "1.15.1 horribly broken when it encounters an unknown repo format"
[23:54] <mathrick> 1.3 correctly barfs on unknown format, FWIW
[23:56] <mwhudson> igc: now fix all the loggerhead bugs!!
[23:56] <igc> mwhudson: wow - that's service!
[23:56] <igc> I only applied for membership 30 seconds ago :-)
[23:57] <mwhudson> i guess i saw the mail as it arrived by chance
[23:59] <lifeless> mathrick: interesting
[23:59] <AfC> lifeless: right, but surely if the write failes you can check for the directory's existence and just mkdir the damn thing rather than failing back to the user
[23:59] <lifeless> AfC: we can try I guess, but error handling like that tends to go wrong IME
[23:59] <poolie> rebooting