[00:37] <poolie> hi spiv
[00:45] <spiv> Hi poolie
[01:31] <yhager> lifeless: yes, I guess I will. I want to read a bit more first...but the minimum exported version is (2, 3, 0),
[01:31] <yhager> oops..
[01:31] <yhager> I installed bzr latest (2.3b4) and latest bzr-svn, but bzr-svn seem to be too old?
[01:33] <maxb> yhager: which bzr-svn are you using?
[01:33] <yhager> 1.0.3 - it's the latest I found
[01:34] <maxb> You probably need the current development version
[01:34] <maxb> bzr branch lp:bzr-svn
[01:35] <yhager> maxb: thanks. It's not very clear from http://wiki.bazaar.canonical.com/BzrForeignBranches/Subversion how to get it (especially to bzr newbies..)
[01:36] <maxb> yhager: Ah. The sad truth is that the wiki is seldom the most up to date about where to get things
[01:37] <yhager> It's usually the first place I go before I bug people on IRC.. :(
[01:37] <maxb> In particular, any time you see a list of versions on wiki.bazaar.canonical.com, don't trust it
[01:37] <maxb> For example, 1.0.4 is out
[01:38] <yhager> hmm..
[01:38] <maxb> jelmer: Would you be opposed to deleting the list of versions from http://wiki.bazaar.canonical.com/ForeignBranches/Subversion and just pointing to the Launchpad project page?
[01:41]  * maxb adds 1.0.4 to the wiki meanwhile
[01:48] <yhager> When I want to create a feature branch, in git, 'git branch' is a very lightweight operation. 'bzr branch' seem to copy the whole branch to a new directory. Is this the same concept?
[01:48] <lifeless> yes, but the default is setup to be more like a full 'cp' - to ease the learning curve
[01:48] <lifeless> sadly this means nontrivial projects often need to do a bit more (and we'll be changing this sometime soon)
[01:49] <lifeless> you might like the bzr-colo plugin
[01:49] <lifeless> which gives you multiple branches in one directory
[01:49] <lifeless> or setup a 'shared repository' (using bzr init-repo), and branch into that
[01:49] <lifeless> there are docs for both these I think, on the docs website
[01:55] <yhager> I read about shared-repository, but did not really understand what it does. I
[01:56] <yhager> I 'bzr init-repo', then cd into that, and branch from there?
[01:57] <maxb> yhager: A shared repository is a way to share revision history disk storage between multiple branches. This saves disk space, and also makes branching faster because none of the history needs to be copied
[01:59] <yhager> maxb: but still, it copies the whole directory..
[01:59] <maxb> The working tree, you mean?
[01:59] <yhager> maxb: yes. Our project is huge..
[02:00] <yhager> so a shared repository can share info on more than one project? i.e. can I put all my bzr stuff in ~/bzr after the initial 'bzr init-repo ~/bzr' ?
[02:01] <maxb> There's two approaches to working with many branches but a single working tree, you can look at the colo plugin, or you can have a shared repository that contains a number of treeless branches and a single lightweight checkout
[02:02] <yhager> maxb: just measured, it's 2.5GB
[02:02] <maxb> yhager: You can put multiple projects into one shared repository, with the caveat that the process of packing the repository is then over all the projects, not just the project you happen to be working on
[02:03] <yhager> maxb: the way I understand it is that every checkout is lightwieght in a shared repo?
[02:03] <maxb> yes (more or less)
[02:03] <yhager> ok, I see. so I will use a shared repo as a parent dir for all the feature branches.. but still, checking out a branch will mean copying 2.5 GB around..
[02:04] <maxb> why?
[02:04] <maxb> making a new checkout will, yes. So the answer is to only make one of those, and switch it between branches, much as you might do with git
[02:06] <yhager> maxb: ok, I need to read some more. I am confused between checkout and branch now..
[02:08] <maxb> branch == a pointer to a current revision, plus a dictionary of tags
[02:08] <maxb> A branch must have an associated repository somewhere, to actually hold the revisions pointed to
[02:08] <maxb> checkout == A working tree, that is linked to a branch (which is where it puts new revisions when you commit them)
[02:11] <yhager> ok, so a checkout is similar so SVN checkout - all operations are done centrally. Not very interesting if I am trying to make the team switch from SVN
[02:15] <yhager> I have a large team working on an SVN repo of 2.5GB. I want to work with a couple of guys on our own feature branch, and I want to show them the awesomeness of DVCS. What setup would you suggest for this?
[02:16] <yhager> I was thinking of a central repo that imports from SVN, and everyone is branching and pushing to it.. does this make sense? However I am confused on how feature branches can work on a 2.5GB workspace
[03:33] <yhager> In my testing of bzr-svn using a test svn repo, I am now in a situation I cannot push changes anymore to SVN. I get "Operation denied because it would change the mainline history.". Tried rebasing but it does not seem to help
[03:33] <yhager> I prefer to keep append_revisions_only=true
[03:36] <lifeless> sure
[03:36] <lifeless> grab a checkout of your svn branch, do a 'bzr merge otherbranch' and 'bzr commit
[03:44] <yhager> lifeless: it worked! I am trying to understand why. We circumvented the inability to rewrite history in SVN by doing a bzr merge commit, directly onto svn. right?
[03:45] <jam> mgz: I don't know, my python is 2.6.4
[03:45] <jam> lifeless: yeah, I'm still playing, just hit 85 last night
[03:46] <jam> mgz: my py2.6.4's twisted is 10.1 vs 10.2
[03:46] <yhager> lifeless: hmm.. but I lost the individual commits this way..
[03:47] <yhager> This is still far better than git-svn. git-svn rewrites history upon every dcommit (push to svn) - since it adds the svn id to the commit messages. This seems more robust.
[03:48] <lifeless> yhager: right
[03:49] <lifeless> to keep the individual commits you can rebase your local branch and push at the same time using the 'dpush' command.
[03:53] <yhager> lifeless: why would I want to use dpush?
[03:55] <lifeless> yhager: if you wanted to keep the separate commits of a branch done in bzr, when propogating it to svn
[03:56] <yhager> wouldn't this work with push as well? (as long as I am not merging)
[03:56] <lifeless> something like that anyhow - I don't interact with svn these days, so ... I'm not the best advisor
[03:56] <yhager> lifeless: you helped a lot! thanks.
[04:00] <yhager> How can I specify complex layouts of the SVN repo? bzr help svn-import does not help too much...
[04:03] <spiv> yhager: bzr help svn-layout
[04:03] <yhager> spiv: thx
[04:14] <yhager> Darn.. after all this research.. bzr svn-import failed with an internal error...
[04:14] <yhager> I'll try a simpler branch structure..
[04:15] <lifeless> jelmer is pretty responsive to bug reports
[04:15] <lifeless> launchpad.net/bzr-svn
=== MTecknology is now known as Guest61557
=== spm` is now known as spm
=== Guest61557 is now known as MTeck
=== MTeck is now known as MTecknology
[06:15] <jelmer> maxb: I'd prefer to keep the list, as it mentions which bazaar versions are compatible
[06:16] <jelmer> maxb: the list on Launchpad is not authoritative, it's just a mirror of the actual downloads
[06:32] <lifeless> jelmer: what would lp need, to be able to be authoritative
[06:33] <jelmer> lifeless: some place I can just scp/sftp stuff to, or the release-from-tag feature I filed a bug about earlier
[06:37] <jelmer> lifeless: I realise there might also be a command-line tool based around the API nowadays for uploading releases (is there?).  I'm not necessarily opposed to migrating but it means taking some time to dig up that tool, figuring out how it works, and migrating existing tarballs/links.
[06:42] <jelmer> lifeless: at this point hosting the tarballs on launchpad makes things (slightly) more complicated for me, rather than easier (which it should be)
[06:49] <spiv> It would be nice to make launchpad support sftp uploads of download files.
[06:50] <poolie> there is abentley's tool the-kraken
[06:50] <poolie> i think it does this, but i haven't tried it
[06:51] <jelmer> yeah, it can create releases from tags and upload them to launchpad. but it needs to be run user side.
[06:51] <spiv> (And scp for that matter)
[06:52] <spiv> I could imagine something like "scp foo.tar.gz foo.tar.gz.asc downloadfiles.launchpad.net:~proj/series/release/" that just DTRT.
[06:53] <spiv> Hmm, I think I've accidentally found a way to tighten one of the HPSS ratchets by deleting redundant code.
[06:55] <poolie> nice, good for you
[06:55] <jelmer> spiv: Yeah, something like that would be neat.
[06:58] <jelmer> poolie: the idea behind the-kraken is nice, but it requires running a tool locally and it requires per-project configuration that you need to carry around with the project.
[06:58] <lifeless> jelmer: you should reopen that release from tag bug or something
[06:58] <poolie> mm, that's a shame
[06:58] <lifeless> I think it would be very nice
[06:59] <poolie> it seems like there is generally a gap between "patch to launchpad itself" and "tool people need to run on their own machines"
[06:59] <poolie> in theory you could run a kraken-like thing on a server somewhere, even using oauth
[06:59] <poolie> but it does not seem to often be done
[07:03] <lifeless> its hugely more convenient and discoverable to have links in the webui
[07:03] <lifeless> one could add such links and docs to external tools, of course
[07:08] <jelmer> poolie: it would be nice if launchpad supported push notifications to help with that sort of thing.
[07:08] <jelmer> lifeless: I'll follow up on the bug.
[07:08] <poolie> agree
[07:13] <jelmer> lifeless: Looks like I already followed up to Aaron's last reply earlier.
[07:16] <lifeless> jelmer: kk
[07:16] <lifeless> jelmer: I thought it was closed, clearly I'm wrong ;)
[07:16] <lifeless> jelmer: what is its status?
[07:17] <jelmer> Its status is "Opinion", not sure whether that counts as Closed :-)
[07:18] <jelmer> bug 673407
[07:18] <ubot5`> Launchpad bug 673407 in Launchpad Bazaar Integration "automatic tarball creation for tags" [Medium,Opinion] https://launchpad.net/bugs/673407
[07:18] <lifeless> bah
[07:18] <lifeless> thats closed
[07:18] <poolie> aka "that's your opinion" :)
[07:37] <vila> hi all
[07:40] <vila> hi jelmer
[07:41] <jelmer> vila: moin
[07:41] <poolie> hi there
[07:41]  * vila jumps (silly volume control staid on very high...)
[08:16] <jelmer> vila: I uploaded bzr-upload 1.0 to Debian the other day, should land in natty soon.
[08:17] <jelmer> vila: Only a few more broken bzr-related daily builds remaining now.. bzr-search, bzr-dbus, bzr-email and bzr-xmloutput
=== beaumonta is now known as abeaumont_
[08:20] <vila> jelmer: rmadison says 1.0.0 is in natty already
[08:20] <jelmer> vila: hmm, that was quick! Never mind me then :-)
[08:20] <vila> jelmer: I've seen weird failures for the daily builds about truncated time stamps
[08:22] <vila> jelmer: I was wondering if they were related to py27 ?
[08:23] <jelmer> vila: I don't recall seeing any; there were some related to python-testtools and py27 a while ago but those should be fixed now
[08:24] <jelmer> the 4 packages I mentioned are all failing because of failures in their test suites.
[08:24] <poolie> does bzr choose base texts using the per-file graph now?
[08:27] <vila> poolie: I don't think so (well, IIUC you mean by first establishing this graph)
[08:27] <vila> jelmer: so presumably old failures right ?
[08:27] <vila> jelmer: yes, I was referring to semi-old failures and testtools was among the suspects
[08:28] <jelmer> vila: the testtools related issues should be fixed now as far as I can tell, these remaining issues are AFAIK all due to API changes in bzrlib
[08:28] <vila> jelmer: ok
[08:29] <jelmer> except for bzr-email perhaps, I'm not entirely sure what's going on there
[08:34] <vila> jelmer: looks like it's config related
[08:40] <vila> jelmer: fixed
[08:40] <poolie> vila: see my pm?
[08:40] <vila> jelmer: well, fixed but requires a new-ish bzr
[08:41]  * poolie is going soon
[08:41] <vila> poolie: oops
[08:43] <vila> jelmer: the fix is only in the tests so I don't think we should spend time ensuring compatibility there... or not ?
[08:45] <jelmer> vila: how hard would it be to fix compatibility?
[08:46] <jelmer> vila: Hmm, nevermind - I was thinking of older Ubuntu releases but I guess those should be fine as long as we have a newer bzr?
[08:46] <vila> jelmer: http://paste.ubuntu.com/543473/ is the fix, so it could certainly be made compatible
[08:46] <vila> jelmer: exactly
[08:47] <vila> jelmer: people using old bzr versions will still be able to use the plugin
[08:47] <vila> jelmer: if they care about running the tests... I'd be surprised if they don't want to upgrade...
[08:47] <vila> jelmer: should I push this fix ?
[08:48] <jelmer> vila: yeah, that seems reasonable
[08:48] <jelmer> vila: please do, thanks for fixing this!
[08:48] <vila> jelmer: done
[09:33] <cvv> Hi all?
[09:34] <cvv> is currently here Vincent Ladeuil?
[09:35] <vila> cvv: Vitaly ?
[09:36] <vila> cvv: yeah, that should be you :) bug #684728 has some 'cvv' in the paths :)
[09:36] <ubot5`> Launchpad bug 684728 in Bazaar "bzr push refuse with message "bzr: ERROR: Working tree "/root/projects/games/logic/v2/cvv-dev/" has uncommitted changes (See bzr status). Use --no-strict to force the push." on clean tree" [Undecided,Incomplete] https://launchpad.net/bugs/684728
[09:36] <cvv> Yes, I'm Vitaly
[09:37] <vila> cvv: welcome :)
[09:38] <vila> cvv: can you still reproduce the bug if you use 'shelve' instead of 'shelve1' ?
[09:38] <cvv> May be will be interesting for you output of 'bzr info'?
[09:38] <vila> cvv: that too !
[09:38] <vila> !paste
[09:38] <ubot5`> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://tinyurl.com/imagebin | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
[09:39] <spiv> vila: thanks for the review of sprout-does-not-reopen-repo, if you want to look at my reply and make another reply that would be lovely :)
[09:40] <vila> cvv: also, what OS/version are you using ? And are you indeed running bzr as root ? (This may not be related but will help me understand your setup)
[09:40] <vila> spiv: planned
[09:40] <spiv> vila: yay, thank you :)
[09:40] <cvv> mmm. shelve miss some functionality to be replacement for shelve1. I will try during few minutes.
[09:41] <vila> spiv: but roughly: 1) if you don't want import repository, I feel far better 2) I was hoping to give you the energy to nail it, not implying you haven't tried ;-)
[09:41] <spiv> vila: if you want an easier review you can look at https://code.launchpad.net/~spiv/bzr/redundant-missing-keys-check/+merge/43623 ;)
[09:42] <spiv> vila: it deletes more lines than it adds, including release-notes and whats-new :)
[09:42] <vila> spiv: hehe, I think the sprout-does... is more important since it's a pre-requisite, but I'll look at both
[09:42] <vila> cvv: what is missing ? Have a look at shelve --list and unshelve too
[09:44] <vila> spiv: just checking: did you try to run the bzr-{svh|hg|git} for sprout ?
[09:45] <vila> jelmer: if you could have a brief look at https://code.edge.launchpad.net/~spiv/bzr/sprout-does-not-reopen-repo/+merge/41037 that would be nice !
[09:48]  * jelmer looks
[09:49] <cvv> viva: I frequently use shelve, but sometimes I need shelve1 functionality. I try to reproduce bug with shelve and found out then my bug is unreproducible with shelve.
[09:49] <cvv> viva: only with shelve1
[09:49] <vila> jelmer: I'm looking at the xmloutput failure but... it looks quite complicated... that's the perfect example of why CI is needed to get faster feedback... I wonder when this started failing
[09:50] <vila> cvv: haaaa, good, huge progress
[09:50] <vila> cvv: so what is missing in shelve that shelve1 provides ?
[09:52] <jelmer> vila: yeah, I didn't see anything obvious that was the culprit in bzr-xmloutput either.
[09:53] <jelmer> maybe we can convince beuno or verterok to have a look?
[09:53] <cvv> vila: output of bzr info -v: http://paste.ubuntu.com/543492/
[09:54] <vila> jelmer: may be, but this sounds like a bzr change is the culprit there...
[09:55] <vila> cvv: wow, you're using a very old bzr format, upgrading will get you smaller repositories and faster operations (let's finish diagnosing your actual problem first though)
[09:57] <vila> cvv: the 'bzr info' output is fine, nothing wrong here
[09:58] <cvv> vila: one second
[09:58] <vila> cvv: sure
[10:01] <maxb> jelmer: The problem with versions on the wiki is that the lists inevitably get out of date. If they are to stay, we need a better way of remembering to update them
[10:02] <jelmer> maxb: I update it when I do a release, but obviously I forgot last time.
[10:04] <cvv> vila: that's  was false alarm.
[10:04] <maxb> ok. It's just conversations here involving users mislead by stale wiki pages appear to be somewhat commonplace (in general, not just for bzr-svn)
[10:08] <vila> jelmer: meh, bzr-email failing because it can't import testtools ? wth ?
[10:08] <jelmer> vila: where is that?
[10:08] <vila> jelmer: https://launchpad.net/~bzr/+archive/daily/+build/2096278/+files/buildlog_ubuntu-karmic-i386.bzr-email_0.0.1%7Ebzr45%7Eppa53%2B53%7Ekarmic1_FAILEDTOBUILD.txt.gz
[10:09] <vila> oh, karmic ?
[10:09] <cvv> vila: I currently log out. If there will any ideas about additional interesting or useful info - I will be happy to give.
[10:10] <vila> cvv: you didn't tell what is missing from shelve1 ?
[10:10] <vila> argh
[10:10] <jelmer> vila: Yeah.. looks like the version of testtool is too old
[10:12] <vila> jelmer: but where ? I don't get which archives/ppa are involved here nor where you specify them
[10:13] <vila> Get:40 http://ftpmaster.internal karmic/universe python-testtools 0.1~r16-0ubuntu1 [8504B] is certainly weird
[10:14] <jelmer> vila: Each PPA has a link "Edit PPA dependencies" where you can specify the other PPA's that will be used to install dependencies
[10:14] <jelmer> it might make sense to add "ppa:testing-cabal/archive" for the newer testtools
[10:14] <vila> why not the bzr-beta ppa instead ?
[10:17] <jelmer> vila: either works I guess
[10:17] <jelmer> testing-cabal/archive has daily builds of testtools so is likely to be more recent, but I'm not sure how important that is
[10:19] <vila> well, from babune, I had mixed experiences tracking testtoosl/subunit tips, bzr-beta will be updated less often but should be 1) less likely to fail, 2) broader than testing-cabal if there are more dependencies (cross plugins ?)
[10:20] <jelmer> the daily builds run the test suites so broken tips shouldn't be an issue
[10:20] <jelmer> is there no PPA with just bzr build dependencies?
[10:21] <jelmer> I'd just like to make sure we build the plugin daily builds against e.g. the bzr daily build rather than the release
[10:21] <vila> testtools is not strictly a build dependency, I think that an issue that has been discussed in the past
[10:21] <vila> oh
[10:21] <vila> s/that/that's/
[10:22] <vila> bah, know issue is what I meant
[10:22] <vila> known
[10:22] <vila> wow, tyops attack !
[10:22] <jelmer> adding a PPA to the dependencies won't pull in its packages, it'll just mean that PPA will get used during the build.
[10:22] <vila> good point about daily bzr though
[10:23] <vila> right, so you did add testing cabal since this failed build right ? (looking at https://launchpad.net/~bzr/+archive/daily/+edit-dependencies right now)
[10:23] <vila> . o O (Would you stop adding 'right' at the beginning *and* the end please ?)
[10:23] <jelmer> :-)
[10:24] <jelmer> Yeah, I did add the testing cabal PPA to the dependencies earlier
[10:24] <vila> haaaa, but it doesn't contain the packages for karmic
[10:24] <vila> only lucid/maverick/natty
[10:24] <spiv> vila: I haven't run the foreign vcs plugins, I expect they will need to be updated for the new signatures
[10:25] <spiv> vila: but the new signatures will work ok with old bzrs, so it's not too bad
[10:25] <vila> spiv: meh, you lost me here
[10:25] <jelmer> vila: I suspect there was a reason we couldn't build on karmic, but I don't remember off the top of my head.
[10:26] <spiv> vila: the sprout patch adds params to stuff like BranchFormat.open
[10:26] <vila> if plugins use the new parameters, surely they won't work with old bzrs
[10:26] <spiv> vila: so I expect SvnBranchFormat.open (or whatever it is called) will need to add the new param to its definition
[10:26] <vila> urgh
[10:26] <spiv> vila: it can even ignore the new param, it just has to allow it to be passed.  It's an optional param.
[10:27] <vila> yeah, got it now
[10:28] <spiv> (ideally they'd use it rather than ignore it of course)
[10:28] <maxb> I wonder, if we should have a status wiki page for collaborative notes on investigations of ~bzr daily recipe build failures
[10:29] <jelmer> maxb: I'd like to see +recipes page that lists the failures.
[10:29] <jelmer> *a
[10:32] <jelmer> maxb: As far as I know there are only three failures left, in bzr-xmloutput, bzr-search and bzr-dbus. They're not specific to the daily builds.
[10:36] <vila> Some of them may be worth filing as bugs
[10:37] <vila> jelmer: the bzr-search failures all point to the *same* root cause apparently
[10:37] <vila> jelmer: by the way (dunno if it applies to your recipes) you know you can use BZR_PLUGINS_AT=xxx@.
[10:38] <jelmer> vila: that's what they're using.
[10:38] <vila> I mean a single '.'
[10:38] <vila> That may seem a bit unsafe in scripts but in interactive use it's neat ;)
[10:39] <jelmer> vila: IIRC that doesn't always work for me, when plugins use chdir() and relative imports.
[10:41] <vila> jelmer: ok, file bugs next time ;)
[10:42] <vila> or not...
[10:42] <jelmer> vila: well, is that really a bug?
[10:42] <vila> I just happen to use it for plugins that I don't install
[10:42] <jelmer> I generally use BZR_PLUGINS_AT="svn@`pwd`"
[10:43] <vila> jelmer: well, I'm not sure where the bug is in this case, chdir() and relative imports in plugins are... borderline to me ;)
[10:43] <vila> yeah `pwd` is safer (I use it too, I realized '.' allowed me to be even more lazy ;)
=== soren_ is now known as soren
[13:07] <knittl> how can i describe LCA merge in one o r two sentences?
=== smoser` is now known as smoser
=== vednis is now known as mars
=== vednis is now known as mars
=== Ursinha is now known as Ursinha-lunch
[14:40] <AdamDV|iPad> Just looking at the documentation, and trying to understand the difference between a merge and a pull. A pull allows you to grab the code if you don't intend to make changes to it, right?
[14:41] <AdamDV|iPad> And then you could branch and commit and remerge if your going to change the code, and by sending the code back to the maintainers, they can approve it and merge your code back into the master branch?
[14:41] <fullermd> Loosely speaking, pull is for maintaining a mirror; merge is for combining outside changes with your own.
[14:41] <AdamDV|iPad> I see.
[14:41] <maxb> pull == bring some history, which is a strict superset of what I already have, from over there, to my local branch
[14:42] <AdamDV|iPad> Alright.
[14:43] <AdamDV|iPad> And if I do a 'bzr send -o file.patch' it will output file.ptch which I can then email to the project maintainers (pr somehow get it to him)?
[14:43] <AdamDV|iPad> And what command would be run on the server to merge changes from the patch file to the master branch?
[14:44] <maxb> I think you can 'bzr merge' from a bundle
[14:44] <AdamDV|iPad> Bundle?
[14:45] <vila> 'send' produces bundles (there is more than just the patch in them)
[14:45] <AdamDV|iPad> I see.
[14:45] <vila> but using branches is preferred over bundles when possible since you can reuse them
[14:45] <AdamDV|iPad> But, contradictory to the name, bar send does not actually upload any code into the meter branch, correct?
[14:46] <vila> 'send' is for mail
[14:46] <AdamDV|iPad> Well, how would you submit code for approval without using a bundle?
[14:46] <AdamDV|iPad> Alright.
[14:46] <vila> by publishing a branch somewhere
[14:46] <vila> http/ftp/sftp server
[14:46] <AdamDV|iPad> Hmm
[14:47] <vila> or on launchpad
[14:47] <vila> have a look at merge proposals there and how they can be reviewed
[14:47] <AdamDV|iPad> And then the maintainer would merge from you published branch, right?
[14:47] <AdamDV|iPad> Your*
[14:48] <vila> through a dialog between a submitter and the maintainer the branch evolves without the need to send multiple mails (even if mail can be used to interact with launchpad)
[14:48] <vila> yes, merge accept branches and bumdles
[14:48] <vila> bundles
[14:49] <AdamDV|iPad> I see.
[14:50] <AdamDV|iPad> But if your merging from a branch and not a bundle, doesn't that mean that each branch being merged from or submitted for merging has t be stord in it's own directory on the server?
[14:50] <AdamDV|iPad> Or, away from the master branch?
[14:53] <vila> yes, they are separate branches
[14:54] <vila> But that doesn't mean they can't share history :)
[14:54] <AdamDV|iPad> Of course not :)
[14:54] <AdamDV|iPad> I see. I'll probably be back. Gonna go read the doc some more.
[14:54] <vila> By that I mean at the storage level too (search for shared repositories)
[14:56] <vila> my ISP has gone mad again...
[14:59] <vila> ...their new DSL modem will now also includes a blu-ray drive, a 250GB HDD, DECT support, 3G, Wifi-n HDTV
[14:59] <vila> oh, I forgot the accelerometer and gyro in the remote ...
[15:00] <fullermd> It can't read email?  What a piece of junk.
[15:00] <vila> ...
[15:00] <vila> ... you can... if you have a TV...
[15:00] <fullermd> Ugh.  Who wants THAT?
[15:01] <vila> did I mention support for optic fiber ?
[15:01] <vila> and the game pad ?
[15:02] <vila> poor other french DSL ISPs they have just produced new boxes to compete with the old one...
=== zyga is now known as zyga-food
[15:16] <vila> jam: hello ! Thanks for the review ;)
[15:16] <jam> morning vila]
[15:16] <jam> np
[15:16] <jam> sorry about the delay
[15:18] <vila> jam: np, that wasn't an important change, just a cleanup ;)
[15:19] <vila> jam: but for the sphinx one, I think I answered your review and I'd like to make babune a bit more blue ;)
[15:20] <vila> https://code.edge.launchpad.net/~vila/bzr/688072-skip-sphinx-failures/+merge/43227
[15:20] <vila> courtesy URL :)
[15:20] <jam> vila: well, I did say "I'm fine with this", sorry for not giving an actual vote
[15:21] <vila> ha, I'm always unclear about implied votes :-/
[15:21] <vila> err, confused I meant
[15:21] <jam> if it seems like an approve, and it takes a week to get a response, it *is* an approve
[15:21] <jam> (heck, if it takes a week, it *is* an approve anyway, :))
[15:22] <fullermd> vila: Speaking of votes, does that combination of your and my changes on smooth-upgrades satisfy your Needs-Fixing?
[15:23] <vila> fullermd: shudder, almost, I'd like to get rid of the not-so-useful-so-let's-not-add-stuff-requiring-maintenance helper
[15:23] <vila> I'll get to that asap and nag the pp from there
[15:24] <vila> ...or not
[15:24] <vila> hmm
[15:24] <fullermd> Who...   oh, yes.  I'd want to hear from him anyway, since he was the last comment on igc's original MP.
[15:35] <vila> fullermd: by the way,feeling better ?
=== Ursinha-lunch is now known as Ursinha
[15:39] <fullermd> Oh, fairly.  I can breathe again.  Just the trailing ends to deal with for some days to come probably.
[15:39] <vila> fullermd: good ;)
[15:49] <RenatoSilva> I have a merge which will add new files, how to avoid these files to be added?
[15:49] <RenatoSilva> bzr remove them doesnt' work, it'd be something like bzr unadd
[15:50] <RenatoSilva> oh bzr revert them
[15:50] <RenatoSilva> never mind
[15:53] <vila> ultimate support via IRC !!
=== beuno is now known as beuno-lunch
=== ubot5` is now known as ubot5
=== Odd_Blok1 is now known as Odd_Bloke
[16:53] <yhager> unfortunately bzr-svn fails on me with sqlite3 errors, and I can't install tdb. See https://bugs.launchpad.net/bzr-svn/+bug/685251/comments/4. That's too bad, cause bzr-svn seems very solid to me.
[16:53] <ubot5> Ubuntu bug 685251 in Bazaar Subversion Plugin "bzr-svn aborts instead of waiting if its sqlite DB is locked" [Low,Triaged]
[16:54] <jelmer> yhager, do you really need to use multiple instances of bzr at the same time?
[16:54] <yhager> jelmer: nope
[16:54] <jelmer> yhager, sqlite shouldn't give that error if you have only a single instance of bzr-svn running
[16:55] <yhager> jelmer: well, I only run a single 'bzr svn-import'
=== zyga-food is now known as zyga-waiting-for
[16:55] <yhager> jelmer: thanks for helping me on this
[16:56] <jelmer> yhager, that's strange, I haven't seen that before
[16:56] <jelmer> yhager, another thing you can try is to disable the cache altogether, but that will have some performance implications
[16:56] <yhager> jelmer: how?
[16:57] <jelmer> yhager, set "use-cache = False" in the relevant section in ~/.bazaar/subversion.conf
[16:57] <jelmer> or perhaps just in ~/.bazaar/bazaar.conf
[16:58] <yhager> ok. I need to unfold my python2.7 source compiling, and go back to the previous setup. Now it doesn't even run...
[16:59] <yhager> darn, no uninstall for this
=== deryck is now known as deryck[lunch]
[17:14] <yhager> jelmer: Usually it failed in the getting branch info (at ~4k revisions out of 24k). I ran with use-cache = False, and now it is already in the "copying revisions" phase..
=== beuno-lunch is now known as beuno
[17:46] <RenatoSilva> Imagine I patch a given changeset of some project and I need to update the patch as new changesets are introduced in upstream. It is a mercurial repository, so I import it into launchpad, and merge my patching branch with the latest changed on that branch. The problem is, how do I generate the patch? This workflow is not making sense to me
[17:47] <yhager> jelmer: so far so good. use-cache = False seem to have been a good workaround. (copying revision 7094/22784) :)
[17:47] <RenatoSilva> *latest changes
[17:49] <RenatoSilva> in my mind, the workflow which would allow me to generate the patch is branch the imported branch, and merge from the patching branch
[17:51] <RenatoSilva> the problem is that I'd need to do revolve merge conflicts every time there's a new changeset in upstream, this is boring
[17:51] <RenatoSilva> * resolve
[17:51] <RenatoSilva> does anyone understand what I mean?
[17:53] <vila> roughly
[17:54] <yhager> jelmer: oops.. bzr: out of memory
[17:54] <vila> you mention two problems here: one is getting your patch up to date, the other is the conflicts
[17:54] <vila> for the patch, I don't see why one workflow will give you a patch different than the other but if you're more comfortable with it, just use it
[17:55] <vila> for the conflicts, I think you will get the same whatever your workflow is but it's hard to guess which kind of conflicts you're getting
[18:00] <RenatoSilva> vila: let's say I use the first workflow and my patching branch looks like this: 1. Initial commit from upstream release 1.0, 2. My patch, 3. Merge upstream changeset 123, 4. Merge upstream changeset 124, 5. Improve my patch, 6. Merge upstream changeset 125
[18:01] <RenatoSilva> vila: then they want to apply my patch in changeset 126. I need to provide them a component.patch, but I can't figure out how exactly...
[18:02] <vila> then you get your patch against upstream with 'diff -rsubmit:' probably
[18:03] <vila> submit: will use whatever branch is named submit_branch in the output of 'bzr info'
[18:04] <RenatoSilva> bzr diff -rsubmit: imported-hg-branch?
[18:04] <vila> just 'submit:' , it will use the right branch
[18:05] <vila> well, "right", most of the time, check 'bzr info'
[18:09] <RenatoSilva> but the right branch is not what's in bzr info by definition
=== deryck[lunch] is now known as deryck
[18:10] <RenatoSilva> what operation makes a branch get into bzr info as the submit branch?
[18:11] <vila> merge
[18:11] <vila> merge --remember will set it again
[18:13] <RenatoSilva> hmm ok, so I just need to keep bzr merging with upstream, and if they accept the patch, I just need a bzr diff -rsubmit:
[18:14] <vila> another way to get it is to do 'bzr merge --preview ../feature' in your mirror
[18:17] <RenatoSilva> bzr -rsubmit: will make a diff bewteen the submit branch and current one, starting from the common revision. It will differentiate between the commits in current branch which are just merges and the ones which are real diffs from upstream, so resulting patch will just contain my changes not the merges. Did I understand correctly?
[18:18] <vila> yes, try it ;)
[18:20] <RenatoSilva> vila: ok thanks.
[18:24] <RenatoSilva> vila: if I understand correctly: the problem with that second approach is that if I just wait them to accept the patch, it could have passed a long time and merging may become complicated. I think it's better to rather update the patch itself regularly. I could do this with that approach, but I think I'd need to be resolving the same merge conflicts again and again, whereas in the first approach I sort of "save" them as they appear.
[18:25] <RenatoSilva> *it could have been passed
[18:27] <tacone> hello, bzr behaves badly when called inside a bash script
[18:28] <tacone> it says it has added the files, but it throws a Pointless commit error when I try to commit
[18:28] <RenatoSilva> vila: can't try it while bug 670870 isn't fixed :(
[18:28] <ubot5> Launchpad bug 670870 in Bazaar Hg Plugin "bzr crashed with ValueError in convert_converted_from()" [High,Triaged] https://launchpad.net/bugs/670870
[18:28] <tacone> any advice ?
[18:28] <RenatoSilva> tacone: pastie.org it
[18:29] <tacone> what do you want me to paste ? bzr.log ? the output ?
[18:30] <RenatoSilva> tacone: I'm not sure if I can help at all, but I'd paste your call from script, and bzr output
[18:32] <tacone> http://pastie.org/1376812
[18:35] <RenatoSilva> tacone: from bzr help add:  "--dry-run will show which files would be added, but not actually add them."
[18:35] <tacone> omg
[18:59] <yhager> In bzr-svn, can I just 'bzr checkout' the SVN repo, have people branch this out. Can then changes then be pushed all the way back to SVN?
[19:01] <yhager> What I mean is: bzr checkout svn://svn svn; bzr branch svn bzr-svn-branch; and then push commits from bzr-svn-branch all the way to svn - is this possible?
[19:02] <maxb> yes
[19:02] <maxb> although merging will be required first if anyone commits to svn
[19:06] <yhager> is there a way to do a lightweight checkout from SVN?
[19:17] <maxb> I wouldn't recommend it
[19:17] <maxb> You'd be forcing bzr-svn to reconvert bits and pieces all the time, the performance would be abysmal
[19:44] <yhager> ok. Is there a way to svn-import partial history, e.g. just the last 6 months?
[19:48] <RenatoSilva> Any highlight on how to fix this error? http://pastie.org/1377048
[19:48] <RenatoSilva> bzr-hg is the latest repository version
=== zyga-waiting-for is now known as zyga
=== _thumper_ is now known as thumper
=== oubiwann is now known as oubiwann-holiday
[21:35] <poolie> hi all
[22:05] <spiv> Good morning
[22:08] <poolie> hey there spiv
[22:09] <poolie> how are you?
=== Ursinha is now known as Ursinha-afk
[22:13] <spiv> Good.  Happy to have https://code.launchpad.net/~spiv/bzr/sprout-does-not-reopen-repo/+merge/41037 unblocked!
[22:14] <poolie> oh, great
[22:14] <poolie> i saw the cover letter
[22:16] <yhager> I found out what causes 'bzr svn-import' to go out of memory - a 600MB iso file was added in a revision. I don't care about that file - can I ignore it for the import?
[22:22] <poolie> yhager: i don't know of a way to do it
[23:01] <poolie> yhager: perhaps you can use svn history editing (dump/reload?) to get it out of the history there?
[23:01] <yhager> poolie: hmm.. Can I do that without access to the subversion server?
[23:01] <poolie> sorry, no
[23:02] <yhager> poolie: ok. is the svn dump a format I can edit?
[23:02] <poolie> i suggest you send mail to the list, and somebody else might know more
[23:02] <yhager> I opened a bug on this..
[23:02] <yhager> I'm trying to hack it somehow now..
=== sipsniffa1 is now known as sipsniffa