[07:24] <Wiz-KeeD> hey guys
[07:24] <Wiz-KeeD> anyone around
[07:24] <Wiz-KeeD> ?
[07:26] <Wiz-KeeD> hello jam
[07:26] <Wiz-KeeD> Can someone please tell me, when I make a push to a branch and it makes some automated merges leaving messages inside the actual files
[07:27] <Wiz-KeeD> How do I detect those in the branch? it's messing up my code and I want to resolve it
[07:27] <jam> Wiz-KeeD: we don't ever "automated merge" when doing push. Do you mean during "bzr merge" ? Or "bzr pull" ?
[07:27] <bob2> you shouldn't push to things with working copies
[07:27] <jam> generally, you use "bzr status"
[07:28] <Wiz-KeeD> bob2, i shouldn't?
[07:28] <jam> hmmm.. maybe we do with local push, that was a special case
[07:28] <Wiz-KeeD> That's how I deploy my code to the server
[07:28] <bob2> it in fact refuses by default
[07:28] <bob2> Wiz-KeeD, that's a terrible idea
[07:28] <Wiz-KeeD> bob2 how so? what would be your suggestion?
[07:28] <Wiz-KeeD> to transfer the local code to the server
[07:28] <bob2> because of the above
[07:28] <Wiz-KeeD> i just use bzr push-and-update
[07:28] <Wiz-KeeD> that's it
[07:28] <bob2> also the fact that you /edited things on the server/
[07:29] <bob2> then pushed upon it
[07:29] <Wiz-KeeD> hmm I might have done that but did revert --no-backup
[07:29] <Wiz-KeeD> Then what would be the ideal solution?
[07:30] <bob2> let me guess
[07:30] <bob2> php?
[07:30] <Wiz-KeeD> wrong guess :))
[07:30] <Wiz-KeeD> python
[07:31] <bob2> deploying python via this method is absurd
[07:31] <bob2> since you're missing the './bin/python setup.py develop' or './bin/pip install -e .' step
[07:32] <Wiz-KeeD> I don't understand
[07:34] <Wiz-KeeD> I deploy personal code to a server regarding modules of a framework that get loaded by that framework on the server
[07:34] <Wiz-KeeD> And any changes I make and test locally I will eventually have to push onto the server for production
[07:35] <Wiz-KeeD> Might not be the best method but I don't see how that is absurd really, maybe I'm missing something
[23:40] <achiang> hello. i have a large branch that i do not want to re-clone from launchpad. i made changes in this branch and pushed them to LP, then submitted a merge, and it was approved
[23:41] <achiang> now, i want to start from a pristine trunk, and do a bzr merge from lp:~achiang/project/proposed-branch
[23:41] <achiang> and then push the merged trunk to lp:project
[23:41] <achiang> is there a way to get back to "trunk" using my local, modified branch?
[23:42] <fullermd> Was it branched off trunk in the first place?
[23:42] <achiang> yes
[23:42] <fullermd> Try pull.
[23:42] <achiang> ?
[23:43] <achiang> so bzr pull lp:project ?
[23:43] <achiang> inside the modified branch?
[23:43] <fullermd> Just bzr pull should be enough.
[23:43] <achiang> i get "no revisions or tags to pull"
[23:44] <fullermd> See what bzr missing lp:project has to say.
[23:45] <achiang> simply says that my local branch has 5 extra revisions, but trunk has not changed since i last cloned/pulled
[23:45] <fullermd> Mmm.  OK, let me check this then.
[23:46] <fullermd> You branched lp:project, then made 5 commits on top of it.  Pushed them to lp:~achiang[...].
[23:46] <achiang> i suppose i could just push to lp:project, but something weird in me wants to ensure that trunk gets a merge commit...
[23:46] <fullermd> Now you want to take a prisine lp:project, merge lp:~achiang[...] into it, commit the merge, then push that?
[23:47] <achiang> fullermd: yes you understand correctly. is that weird for me to want?
[23:47] <fullermd> Eh.  Not particularly.  6.5 of one, half a baker's dozen of the other.
[23:48] <achiang> in git, it would resolve to the same thing anyway... what they call a fast forward merge (or whatever)
[23:48] <fullermd> The q&d answer is probably do to a pull --overwrite to force your local branch back to pure trunk, then do the merge/ci/push.
[23:48] <achiang> but i guess i'm used to seeing merge commit in bzr workflows
[23:48] <achiang> oh, nice. i'll do the --overwrite
[23:48] <fullermd> Naturally.  'cuz bzr may have smoked whatever git was on, but it didn't inhale   ;p
[23:50] <achiang> ugh, that screwed up my tree
[23:50] <achiang> because i had stuff in a subdirectory that wasn't tracked by bzr
[23:50] <fullermd> If it's gonna be a long-term repeated action, better solution would be to setup a local shared repo and keep one branch as pristine trunk, using additional locals for the work branches.
[23:51] <achiang> yah. that's what i'm about to do
[23:51] <fullermd> Precious stuff?
[23:52] <fullermd> If not, you can just do some rm and/or revert dancing.
[23:52] <achiang> i'm recovered now... rm -rf subdir/ ; bzr revert ; bzr status => clean :)
[23:52] <fullermd> I said it first!  That means I still get the credit!
[23:53] <achiang> i can show you my bash history timestamped to an ntp-synced machine :P
[23:54]  * achiang now does cd .. ; mv local trunk ; bzr branch trunk local
[23:54] <achiang> fullermd: thanks for the help, much appreciated
[23:54] <fullermd> I'd setup the repo first, to save all the I/O on your poor disk.
[23:55] <achiang> it was ok. only took a few seconds for the local branch
[23:55] <fullermd> I blame the TAI/UTC offset for that vile attempt to snake the credit away from me.  Durn leap seconds.
[23:55] <achiang> the reason the branch is huge is because of media files in the tree
[23:55] <achiang> i guess that was fast enough to clone locally
[23:55] <achiang> that, plus PCIe SSD
[23:55] <fullermd> Well, it's doubling the repo space used.
[23:56] <fullermd> (since it's now storing the whole history twice)
[23:56] <achiang> oh, i see
[23:56] <fullermd> One shared repo will stop that.  Plus make any future "branch lp:project/whatever"'s way faster, since they'd only need to grab revs you don't already have.
[23:56] <achiang> got it
[23:57] <fullermd> init-repo to set it up, then reconfigure --use-shared in the branches to switch them over to using it.