[06:01]  * superfly hears a ping drop ;-)
[06:01] <superfly> *pin
[06:01] <superfly> gee, a ping dropping too?
[06:07] <superfly> anyway, when someone is around, I'm getting an error between my local branch and Launchpad which talks about "different serialisers"
[06:08]  * superfly goes to see if he can find the exact error message
[06:08] <jam> superfly: offhand, sounds like a *really* old bzr branch, that probably needs to be updated before it can interchange with the one you have now.
[06:09] <superfly> jam: I was trying to upgrade, and that's what produced this error
[06:09] <jam> superfly: upgrading remotely or locally?
[06:09] <superfly> here we go... bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch-id/40441/.bzr/) is not compatible with RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch/openlp/2.0/.bzr/) different serializers
[06:09] <superfly> jam: remotely, locally went fine
[06:10] <superfly> I'm using a shared repo locally, but I know LP uses stacked branches
[06:10] <jam> superfly: I'm guessing it is old enough that we don't support remote upgrading. If it is on Launchpad, you can just delete it and then re-push over it from your local upgrade.
[06:10] <superfly> however, what that means in practice I am unsure of
[06:10] <superfly> jam: OK, thanks. I'll try that
[13:36]  * jelmer waves to w7z
[13:36] <w7z> hey jelmer!
[13:37] <jelmer> weekending it up? (-:
[13:49] <w7z> just the normal joy of hangouts being worse on nix, so need The Other machine :)
[14:03] <jelmer> w7z: ah :) say hi to John for me
[17:05] <mvo> hello, when I try to branch " bzr branch lp:ubuntu/lucid-proposed/unattended-upgrades" I get a somewhat odd error: "bzr: ERROR: Revision {package-import@ubuntu.com-20111212140141-7wr15t1ycq9jchl0} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))"." - does that mean the branch is damaged on the server?
[17:08] <mgz> mvo: http://package-import.ubuntu.com/status/unattended-upgrades.html
[17:09] <mgz> symptom of someone having futzed with the history. can generally be manually fixed, but there are a limited pool of people able to do that for you.
[17:13] <mvo> mgz: thanks - so thats not smething I could fix myself somehow?
[17:14] <mgz> no, but you can reproduce locally using lp:udd if you follow the setup instructions there and verify a full import works
[17:15] <mgz> that's then only a question of requeuing the package with the right flag rather than some of the other cases which require more violent fixing
[17:15]  * mvo nods
[17:15] <mvo> thanks
[18:34] <InvertedVantage> hi everyone
[18:34] <InvertedVantage> I'm at work so I'll be slow but I have a question
[18:35] <InvertedVantage> I'm looking to implement an SVN solution at my office to help our team manage CAD files
[18:35] <InvertedVantage> I was wondering what would occur if two people were to check out the same file, modify it, and both submit said files to the server? What if they submitted them at the same time? If they submitted them one after the other?
[18:35] <InvertedVantage> How does SVN and Bazaar handle this? Thank you!
[18:36] <jelmer> InvertedVantage: in both situations, one would get an error saying that their tree was out of date
[18:36] <LeoNerd> In bzr atl east, whoever attempts to submit second gets told their .. what he said
[18:36] <jelmer> they would have to run 'bzr up' to pull in the others changes and then commit again
[18:37] <InvertedVantage> cool, thank you! We have a small team here of about 5 people, all working in the same office. Any recommendations for configuring the set up?
[18:38] <InvertedVantage> And how does Bazaar store previous versions? We can roll back to a previous update if we ever need to, correct?
[18:38] <jelmer> InvertedVantage: yep, you can roll back
[18:38] <jelmer> InvertedVantage: I would recommend having a look at the workflows chapter in the bzr docs
[18:38] <InvertedVantage> thank you so much :) I'll take a look once we're done with this project. You've been a huge help!
[18:39] <InvertedVantage> cheers!
[23:22] <Wiz_KeeD> hey guys
[23:23] <Wiz_KeeD> how do i check a branches name?
[23:23] <Wiz_KeeD> how do i know where i got it from so i can bzr branch in another location?
[23:26] <Logan_> bzr info
[23:26] <Wiz_KeeD> yay found it in the command list in the meantime
[23:26] <Wiz_KeeD> thank you!
[23:27] <Logan_> No problem. :)
[23:31] <Wiz_KeeD> Logan_, it says bzr+ssh://bazaar.launchpad.net/+branch/magentoerpconnect/magento-module-oerp6.x-stable/
[23:31] <Wiz_KeeD> how can i download that, i see it added bzr-ssh
[23:31] <Wiz_KeeD> how do i branch it on my local machine?
[23:31] <Logan_> It should be lp:magentoerpconnect/magento-module-oerp6.x-stable
[23:31] <Wiz_KeeD> how can you figure?
[23:31] <Logan_> But you can probably just branch that full URL as well.
[23:32] <Wiz_KeeD> yeah i can doo that but which full url?
[23:32] <Wiz_KeeD> this is what the first one says
[23:32] <Wiz_KeeD>   parent branch: bzr+ssh://bazaar.launchpad.net/+branch/magentoerpconnect/magento-module-oerp6.x-stable/
[23:33] <Logan_> Actually, I just tested it, and the shorthand is lp:magentoerpconnect/magento-module-oerp6.x-stable
[23:33] <Wiz_KeeD> and this is the newly branched one   parent branch: http://bazaar.launchpad.net/~magentoerpconnect-core-editors/magentoerpconnect/module-magento-trunk/
[23:33] <Wiz_KeeD> why's that?
[23:33] <Wiz_KeeD> now what? :-s
[23:34] <Logan_> If you just go to that URL in your browser, and hit "Back to branch summary" in the top left, it will show you how to branch it.
[23:34] <Wiz_KeeD> well it's the same number of revisions
[23:34] <Wiz_KeeD> just different parent branch in bzr info
[23:34] <Wiz_KeeD> :-s
[23:35] <Wiz_KeeD> that worries me a tad
[23:35] <Logan_> They're actually the same branch, just a different way to access it.
[23:36] <Wiz_KeeD> all 3
[23:36] <Wiz_KeeD> i thought so since it's the same revision
[23:36] <Wiz_KeeD> hmm
[23:42] <stewart> hi! I'm having a bit of an issue.
[23:42] <stewart> We have two major versions: let's call them 1.0 and 2.0
[23:42] <stewart> we have developers implement feature/bugfix in 1.0, and propose merging a 1.0 tree and a 2.0 tree into the respective trunks
[23:42] <stewart> and then we merge 2.0 one first, so that 1.0 is only ever a subset of 2.0 revisions
[23:43] <stewart> but... in later merging the 1.0 branch, we get a simple merge commit that then has to be merged into 2.0
[23:43] <stewart> and this causing a bunch of spurious conflicts.
[23:43] <stewart> I'm wondering if there's a way to avoid that?
[23:49] <stewart> actually... I think that question is wrong, and I instead had the wrong branch somewhere in my script.