[00:47] <luke-jr> bzr diff ../server/e/HEAD/ -c 64 | patch -p0
[00:47] <luke-jr> why does that work, yet bzr merge is too stupid to handle it? :/
[00:49] <luke-jr> fuzz 2?
[00:50] <RAOF> luke-jr: Answering that would requrire the message bzr gives as the reason it can't merge.
[00:50] <luke-jr> it just does conflicts galore
[00:51] <luke-jr> I'm merging lp:moo/lambdamoo-1.8 updates into lp:~luke-jr/moo/db_options
[00:56] <RAOF> Hm.  Not really sure.
[01:06] <lifeless> luke-jr: does it detect a criss-cross merge?
[01:06] <luke-jr> lifeless: there is no criss-cross, no
[01:07] <luke-jr> db_options has and never will be merged into lambdamoo
[01:09] <lifeless> luke-jr: its odd that it is conflicting
[01:10] <lifeless> what type of conflicts is it giving?
[01:10] <luke-jr> the MERGE-SOURCE side is trying to add about 500 lines of code that was removed in the branch
[01:12] <lifeless> you could try --weave
[01:12] <luke-jr> haha. no.
[01:13] <luke-jr> weave is evil
[01:15] <lifeless> so you're merging trunk into a branch that hasn't been merged into trunk ever, and its reinstating code that was deleted in the branch ?
[01:16] <luke-jr> correct
[01:16] <luke-jr> trunk is a CVS import, if that is at all relevant
[01:16] <luke-jr> branch was created from a tag in the bzr import
[01:22] <luke-jr> I need to manipulate file-ids. Any advice?
[01:28] <lifeless> why do you need to do that?
[01:29] <luke-jr> telling Bazaar about a rename
[01:29] <lifeless> I think you're getting the conflict because the code that was deleted in the branch was altered in the trunk. Is that potentially accurate?
[01:29] <luke-jr> long after the fact
[01:29] <lifeless> bzr mv --after
[01:29] <luke-jr> it wasn't
[01:29] <luke-jr> lifeless: long after, meaning the commit is 50 revisions ago
[01:29] <lifeless> re the conflicts - in which case please file a bug
[01:29] <lifeless> luke-jr: bzr rm foo --keep; bzr add --file-ids-from [place that has the file] foo
[01:30] <lifeless> luke-jr: also --weave isn't evil, its good - mysql use it all the time to get massively less conflicts
[01:30] <luke-jr> hmm
[01:30] <luke-jr> --weave reduces conflicts, sure, but often it duplicates code
[01:31] <lifeless> does it? I haven't seen that. That would be a bug IMO
[01:31] <luke-jr> O.o
[01:31] <lifeless> basically, feel free to file bugs on merge logic
[01:31] <lifeless> some will be things we can't easily fix without throwing other things out
[01:31] <lifeless> but there is lots of room to improve
[01:32] <luke-jr> the problem-causing merges seem to trigger patch to say "with fuzz 2"
[01:32] <luke-jr> I can only presume that's related
[01:35] <BasicOSX> getting only 8kB from LP everything else fast
[01:37] <luke-jr> lifeless: any way I can ensure I'm not about to totally screw up my branch? XD
[01:37] <luke-jr> bzr status is giving me some funky output ;/
[01:37] <luke-jr> added: db_objects.c
[01:38] <luke-jr> renamed: db_objects.c => db_save_objects.c
[01:38] <luke-jr> modified: db_save_objects.c
[01:38] <luke-jr> does that make sense? :/
[01:39] <lifeless> sure
[01:39] <lifeless> it says that db_objects was modified and renamed
[01:39] <lifeless> and that you have added a new fiel db_objects.c
[01:39] <luke-jr> ok
[01:40] <luke-jr> sigh
[01:40] <luke-jr> trying to tie these merge trees together is a pain
[04:43] <chx> how do i get my working tree into where it was before 9841 was committed?
[04:43] <LeoNerd> bzr revert -r9840
[04:43] <chx> oh
[04:43] <LeoNerd> Or.. more accurately, something like   bzr revert -rparent:9841   but that probably comes down to 9840 anyway
[04:43] <chx> i thought revert was only for reverting changes since last commit.
[04:43] <chx> my bad.
[04:44] <LeoNerd> revert puts it back to the state at some commit.. by default the most recent... but -r can pick a different one
[04:55] <luke-jr> what does -rparent do for merges? :p
[04:57] <Peng_> Hmm, it's "before:", and the help doesn't say.
[04:59] <vinc456> can i reload my bzr.conf file?
[05:00] <vinc456> i've made an edit but the changes don't seem to take effect
[05:03] <Peng_> bzr.conf?
[05:03] <vinc456> sorry branch.conf
[05:08] <Peng_> The changes don't take effect...where? There's nothing to reload
[05:09] <vinc456> well i defined the alias from the tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html
[05:10] <vinc456> but if i try something like 'bzr ll' i get an unknown command error
[05:10] <vinc456> i thought i might have to run some sort of source command, the way i do when i edit .bashrc or something
[05:12] <Peng_> vinc456: Maybe you have to set that in ~/.bazaar/bazaar.conf.
[05:15] <vinc456> Peng_: i set ~/.bzr/branch/branch.conf
[05:16] <vinc456> anyways it's not a big deal
[05:16] <vinc456> it'll probably work fine once the next time i reboot
[05:16] <Peng_> vinc456: Um, no it won't.
[05:16] <Peng_> vinc456: ~/.bazaar/bazaar.conf.
[05:19] <vinc456> Peng_: ah ok, i was confused
[05:19] <vinc456> thanks
[05:45] <seb_kuzminsky> does cherrypicking lose merge tracking?
[05:46] <seb_kuzminsky> i do "bzr merge -c $MY_FAVE_REVNO && bzr merge -c $OTHER_REVNO && bzr commit", and then "bzr log" shows just the final commit, not three new commits (a merge of two previous commits)
[05:46] <seb_kuzminsky> that's on bzr 1.11
[05:48] <Peng_> seb_kuzminsky: That's correct. Which is why we try to avoid cherrypicking. :D
[05:55] <seb_kuzminsky> ok thanks Peng
[05:56] <Peng_> Sorry. :\
[06:00] <BasicOSX> make check-dist-tarball failing on 1.14rc1 release. Anyone able to look at bug 355454 ?
[06:01] <Peng_> I don't think Unicode issues like that are new.
[06:02] <BasicOSX> wasn't an issue 1.13
[06:03] <Peng_> Oh. Never mind then. :D
[06:10] <BasicOSX> interesting bzr selftest passes
[06:13] <Peng_> make check tests with multiple LANG values.
[06:13] <Peng_> So it's more likely to expose Unicode bugs than just selftest.
[06:17] <BasicOSX> Ahh, how it make through PQM? I thought the multiple LANG stuff got put into PQM?
[06:18]  * Peng_ shrugs
[06:19] <BasicOSX> less shrugs, more answer! :-P
[06:21] <Peng_> make check runs with your normal locale and the standard C locale. I'm not sure what PQM does.
[06:22] <Peng_> Maybe your specific locale exposes some bug that PQM's setup doesn't.
[06:22] <Peng_> That's about all the answer I have.
[06:57] <glyph> I've got a branch that I want to push to a public location.  Unfortunately most of the commits were made before I understand how 'bzr whoami' worked, so they are from "Glyph Lefkowitz <glyph@some-random-host-I-use>" rather than "Glyph Lefkowitz <glyph@twistedmatrix.com>"
[06:57] <glyph> Is there a way I can fix up that history?
[06:59] <Peng_> Pretty much no.
[07:00] <glyph> Peng_: Hmm... I guess I should rebase from zero then?
[07:00] <luke-jr> I used cvsps-import to do the initial migration of a CVS upstream to Bzr; how do I get syncs from CVS in?
[07:02] <spiv> glyph: editing a fast-import dump might be relatively painless, if you really care.  (does it really matter?)
[07:03] <glyph> spiv: I don't know.  Does it?  I was under the impression that email address was sort of the primary key for identifying committers.
[07:39] <jkakar> glyph: I trust GPG signed commits as a verification method much more than an email address.
[07:47] <glyph> jkakar: These commits weren't signed either :)
[07:47] <glyph> jkakar: Can I go back and sign them?
[07:48] <bob2> bzr sign-my-commits
[07:56] <glyph> bob2: Huh
[07:56] <glyph> and then if I push somewhere, signatures for old revisions will be published?
[07:56] <bob2> dunno
[07:56] <bob2> also not sure what it'll do wrt your whoami having changed - you might need to temporarily change that back
[07:57] <glyph> bob2: It looks like I can pass a committer on the commandline
[08:09] <lifeless> glyph: no, old revision signatures are not automatically propogated, because thos revisions are not being examined. The library can do it; I guess we should add a flag to push/pull ; I think there is a bug already open
[08:09] <lifeless> glyph: and possibly a hidden command
[08:10] <glyph> I guess for now I will not worry about this
[09:01] <jkakar> glyph: I have this in my ~/.bazaar/locations.conf, which causes all my commits to be GPG signed: http://paste.ubuntu.com/144726/
[09:02] <glyph> jkakar: I'll be adding something like that soon, as soon as I figure out how seahorse-agent works
[09:02] <glyph> (I don't like having gpg private keys on my hard drive)
[09:02] <jkakar> Yeah, that's probably a good call.
[09:02] <jkakar> I was doing the SSH+GPG key on a USB stick thing for a while...
[09:03] <glyph> jkakar: You stopped?
[09:03] <pygi> ok, folks, got a tiny problem with push
[09:03] <jkakar> but then I noticed how much easier it was to steal radix's keys (with USB key attached) at sprints, compared to his whole computer, and decided it might not be so bulletproof.
[09:03] <pygi> http://slexy.org/view/s21qWJI3Rj
[09:04] <jkakar> Though, I guess most of the time my hard drive is potentially more accessible to evil hackers than a USB key in my house, where I spend most of my computing time.
[09:04] <jkakar> glyph: So yeah, I stopped.
[09:04] <jkakar> I'm probably not paranoid enough, oh well.  Ignorance really is bliss. ;)
[09:05] <kizzo> How would I go about undoing a "bzr add"?
[09:05] <kizzo> : )
[09:05] <kizzo> [ removing all of the files that were added b/c of that command.. ]
[09:06] <jkakar> kizzo: rm `bzr added`
[09:06] <lifeless> kizzo: or 'bzr revert' the added files
[09:06] <kizzo> jkakar: That looks like it would actually delete the files from my disk, huh?
[09:07] <kizzo> The first one.
[09:07] <jkakar> kizzo: It will, yes.
[09:07] <kizzo> Oh ok, so revert is probably what I would like to happen then.
[09:07] <kizzo> Cool.
[09:08] <kizzo> Thanks.
[09:09] <pygi> :-/
[09:10] <lifeless> py	whats wrong?
[09:10] <lifeless> pygi: ^
[09:11] <pygi> lifeless, If I knew that'd be good :p
[09:11] <pygi> probably something with the server :P
[09:11] <pygi> lifeless, http://slexy.org/view/s21qWJI3Rj
[09:11] <lifeless> oh, I can't browse right now
[09:13] <pygi> :P
[09:13] <pygi> basically, I can't push :D
[09:13] <lifeless> do you get an error?
[09:13] <pygi> bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'Operation not supported: open_write_stream')
[09:13] <lifeless> that sounds like you have an _extremely_ old server
[09:13] <lifeless> or hmm
[09:13] <lifeless> perhaps its backed onto a readonly transport
[09:14] <lifeless> the latter is more likely I think
[09:14]  * pygi is pretty sure he configured rw privs
[09:15] <pygi> it might be that security subsystem of this server is a bit wonky
[09:15] <pygi> its still pretty fresh
[09:15] <lifeless> are you pushing to bzr+ssh/bzr/bzr+http?
[09:15] <pygi> bzr+http
[09:15] <lifeless> what backing transport did you give it in your glue code?
[09:16] <pygi> hmm
[09:16] <pygi> how do you mean?
[09:17] <lifeless> well to setup a bzr+http server you need some wsgi glue
[09:18] <lifeless> and in that you tell it where the server backend is
[09:18] <lifeless> what url did you use in there
[09:18] <pygi> yup, moment :p
[09:19] <pygi>     local_url = wsgi.local_path_to_url(root)  ?
[09:20] <pygi> I mean, I can branch pretty fine, its probably something in the security code or something :-/
[09:20] <lifeless> no
[09:21] <pygi> (not of bzr security code, but of that wsgi glue/security glue code that you say :)
[09:22] <lifeless> did you follow the howto ?
[09:22] <lifeless> doc/en/user-guide/http_smart_server.txt
[09:23] <pygi> actually, no, purely because I use a custom-written server (clue-bzrsever)
[09:23] <lifeless> ok
[09:23] <lifeless> well
[09:23] <lifeless> cross reference the howto
[09:23] <lifeless> if when you start the backend server you are passing in an http transport its fundamentally wrong
[09:24] <lifeless>     from bzrlib.transport.http import wsgi
[09:24] <lifeless>     smart_server_app = wsgi.make_app(
[09:24] <lifeless>         root='/srv/example.com/www/code',
[09:24] <lifeless>         prefix='/code/',
[09:24] <lifeless>         path_var='REQUEST_URI',
[09:24] <lifeless>         readonly=True,
[09:24] <lifeless>         load_plugins=True,
[09:24] <lifeless>         enable_logging=True)
[09:24] <lifeless> is the key bit
[09:24] <lifeless> root needs to be your on disk path to the root you want to serve out
[09:24] <lifeless> and you'll want readonly=False :)
[09:24] <pygi> :)
[09:26] <pygi> thanks, I'll see what I can do
[09:29] <pygi> hm, ok, readonly IS false
[09:30] <pygi> is this correct:    write = ['mkdir', 'put_file', 'delete', 'rename', 'rmdir', 'append_file', ]  ?
[09:30] <lifeless> that looks like something to do with your custom server
[09:30] <lifeless> its certainly not an accurate list of what bzr uses to push, if thats what you're asking
[09:30] <pygi> can that be the problem?
[09:32] <lifeless> I don't know, I'm guessing at things here
[09:32] <lifeless> what does this custom server do?
[09:32] <lifeless> how does it hook into bzr?
[09:32] <pygi> using bzrlib
[09:33] <lifeless> I mean, it could implement the protocol, or it might subclass the request dispatcher, or handler lookup, or decorate the backing transport, or something else again
[09:33] <lifeless> I have no idea about it, today is the first time I heard of it
[09:34] <lifeless> and without knowing a fair bit more I can't offer good advice :(
[09:34] <pygi> let me check
[09:35] <lifeless> I will note that the open_write_stream method is one on transport that isn't exposed in the smart server API, so its possibly decorating the backing transport
[09:35] <lifeless> in which case giving it a more complete list would be a good idea:)
[09:36] <pygi> could you point me to location where I can find more complete list? :)
[09:36] <lifeless> pydoc bzrlib.transport.Transport is the base class for all transports
[09:36] <lifeless> it defines the public api
[09:38] <lifeless> pygi: what does the custom server do for you?
[09:39] <pygi> serves bzr directories (repos) and handles security
[09:39] <pygi> it seems to define its own ACLTransport ...(or well, at least it has such a class :P)
[09:42] <pygi> (bzr 1.13.1, if it makes any difference)
[09:42] <lifeless> yes, they probably didn't implement the entire contract, only what they saw used
[09:42] <lifeless> bzr 1.13 streams
[09:42] <lifeless> which means the server will use the streaming transport apis
[09:43] <pygi> hm, can that be the problem then? I mean I doubt this was written with 1.13 in mind...
[09:44] <pygi> (and yes, I know I'm bugging, sorry :))
[09:44] <lifeless> I assume so
[09:45]  * pygi goes try with different bzr
[09:45] <pygi> guess I'll just have to submit patches if that's the problem:)
[09:48] <pygi> it seems to need 1.12...
[09:48]  * pygi tries that
[09:55] <pygi> lifeless, ok, different problem: bzr: ERROR: Server sent an unexpected error: ('error', 'Operation not supported: append_file')
[09:55] <pygi> o.O
[10:01] <lifeless> pygi: have you used this software before :) - [is it complete :P]
[10:01] <pygi> lifeless, actually, this is the first time I'm testing it thoroughly :P
[10:01] <pygi> but it is supposed to be complete :p
[10:06] <pygi> don't worry about it, I'll look into the codebase :)
[10:06] <pygi> thanks for all the help
[10:07] <lifeless> np
[10:57] <CBro2007> http://www.pastie.org/437377
[10:57] <CBro2007> guys
[10:57] <CBro2007> guys I was trying to understand this error. can someone help?
[10:58] <CBro2007> http://www.pastie.org/437377
[10:58] <CBro2007> Basically want to get rid of everything in the dir and get a fresh new copy from bzr repository
[10:59] <CBro2007> can someone please help? :)
[11:04] <bob2> bzr break-lock file:///home/dchoon/dcrepo/
[11:04] <Peng_> CBro2007: Check for any bzr process that actually has been running for the last 98 hours. If there aren't any, use "bzr break-lock" -- bah, bob2 is quick.
[11:05] <CBro2007> Peng_: Yeah I just ran the bzr break-lock
[11:05] <CBro2007> it worked
[11:05] <CBro2007> but then I did the "bzr pull --overwrite"
[11:05] <CBro2007> and it still kept all the rest of the files in there
[11:05] <Peng_> Uh-huh...?
[11:05] <Peng_> What files?
[11:05] <bob2> so you deleted some files
[11:05] <bob2> and want them back?
[11:06] <bob2> ala 'xvs update'?
[11:06] <CBro2007> well basically this developer added new files etc... and his version doesn't work
[11:06] <CBro2007> so I suggested overwriting all his local files
[11:06] <bob2> that's not an awesome idea
[11:07] <CBro2007> well basically want to revert back to what was working well...
[11:07] <CBro2007> he has gone ahead and created all these files and ran commands that blurted out lots of stuff that isn't needed
[11:07] <CBro2007> its easier for him to checkout the latest repo copy and start from there
[11:07] <bob2> so, 'bzr revert' will revert to the last commited version
[11:08] <CBro2007> yeah but it might still keep the new stuff?
[11:08] <CBro2007> he has not ADDED his new files
[11:08] <bob2> then delete them
[11:08] <bob2> pull isn't going to delete random un-added files from the working tree
[11:08] <bob2> bzr revert ; bzr clean-tree # revert and delete all unadded files
[11:11] <CBro2007> says unknown command
[11:11] <bob2> it's new
[11:11] <CBro2007> clean-tree is an unkown command
[11:11] <bob2> alternatively, 'bzr status' then manually delete the files
[11:11] <CBro2007> got an older equivalent
[11:11] <bob2> or branch from your repository again
[11:12] <CBro2007> how bout add and then revert?
[11:12] <CBro2007> would that not add all the new files in and then when you revert it gets rid of them all?
[11:17] <LarstiQ> CBro2007: clean-tree used to be in bzrtools before it moved to bzr core
[11:17] <CBro2007> ok
[11:17] <LarstiQ> bzr ls --unknown | xargs rm
[11:18] <LarstiQ> would also work
[11:18] <bob2> as long as there are no spaces in your filenames
[11:18] <LarstiQ> and no directories, but you get the idea
[11:20] <CBro2007> thanks bob2
[11:21] <CBro2007> thats all good now
[11:21] <CBro2007> just a normal delete and then a revert
[13:32] <Stavros> why does bzr insist on messing up my tree when all i want to do is push my local changes upstream?
[13:33] <Stavros> it is interfering with the whole "distributed" paradigm
[13:34] <Stavros> can i just push instead of updating on a bound branch?
[13:36] <beuno> Stavros, yes, but you have to use branches instead of checkouts
[13:36] <beuno> you can use --reconfigure to change a checkout into a branch
[13:37] <Stavros> beuno: i have a checkout right now, and whenever i do a local commit and then try to update, it messes up my working tree
[13:37] <LarstiQ> Stavros: eh?
[13:37] <Stavros> i just want to push the changes, how can i do that?
[13:37] <LarstiQ> Stavros: could you be more specific as to what happens?
[13:37] <Stavros> LarstiQ: i have a bound branch
[13:37] <Stavros> i commit with --local
[13:37] <Stavros> then i update, and my local working directory gets messed up
[13:38] <LarstiQ> please describe 'messed up' a bit more.
[13:38] <james_w> LarstiQ: he doesn't want the merge implied by update
[13:38] <Stavros> bzr thinks there are conflicts, but the revision on the remote repo is one earlier than the local one
[13:38] <LarstiQ> Stavros: that is weird
[13:38] <Stavros> so the remote has rev 60, the local rev 61, and it still merges
[13:38] <james_w> Stavros: why are you doing update? why not just commit?
[13:39] <Stavros> james_w: i did commit once
[13:39] <Stavros> james_w: don't i have to update to push them?
[13:39] <LarstiQ> Stavros: are they the same revision though?
[13:39] <Stavros> LarstiQ: the local repo has one more revision
[13:39] <james_w> Stavros: I don't think so
[13:39] <Stavros> LarstiQ: i'm the only person working on this, so they never diverge
[13:39] <Stavros> james_w: hmm
[13:39] <LarstiQ> Stavros: you do update to merge in changes from the master branch
[13:40] <LarstiQ> Stavros: hah, I diverge myself pretty often, but ok :)
[13:40] <Stavros> LarstiQ: sure, but isn't bzr supposed to know that there haven't been any?
[13:40] <Stavros> now, it tries to sort of "revert" to the master branch
[13:40] <Stavros> and gives me conflicts to what i changed
[13:40] <LarstiQ> Stavros: indeed, so I'm rather suprsised at conflicts.
[13:40] <Stavros> LarstiQ: well yes, but i don't atm :p
[13:40] <Stavros> now i have a pending commit, how do i push it upstream?
[13:40] <LarstiQ> Stavros: commit.
[13:40] <Stavros> with a message again?
[13:41] <Stavros> i don't want to commit my local changes, though
[13:41] <LarstiQ> Stavros: yes, or you can be sneaky.
[13:41] <Stavros> hmm
[13:41] <LarstiQ> Stavros: and bzr pull . -r revid:revidoflocaltip
[13:42] <LarstiQ> Stavros: it does sound like maybe a checkout is not the optimal workflow for you though.
[13:42] <Stavros> i just want to do the equivalent of a push but on a bound branch :/
[13:42] <Stavros> LarstiQ: why not?
[13:42] <LarstiQ> (apart from update pivoting changes when not strictly needed)
[13:42] <Stavros> LarstiQ: i don't want to push each time by hand, so a checkout suits me better
[13:43] <LarstiQ> Stavros: judging from this one case, but maybe the rest of what you do suits better
[13:43] <LarstiQ> Stavros: right, ok
[13:43] <LarstiQ> Stavros: let me mock something up and test if that would work for you
[13:43] <Stavros> so what's the best way to just push my changes?
[13:43] <Stavros> thanks
[13:46] <Stavros> LarstiQ: can you reproduce the update merge, by the way?
[13:47] <LarstiQ> Stavros: the update merge is normal, but it doesn't produce any conflicts for me
[13:47] <Stavros> hmm
[13:48] <Stavros> i had rev 60, committed 61 locally, changed a line in a file, and that line conflicted on update
[13:48]  * LarstiQ pauses his mockup
[13:49] <LarstiQ> Stavros: I'll find you a relevant bug report about the pending merges pivot first
[13:49] <Stavros> hmm ok
[13:49] <Stavros> so it goes, bzr ci, bzr ci --local, change line, bzr up, conflicts
[13:50] <LarstiQ> ah, that is slightly different from what I did, will try it too
[13:50]  * LarstiQ didn't have uncommitted changes prior to the bzr up
[13:50] <Stavros> ah
[13:53] <LarstiQ> hmkay, can't find it from bug titles, back to mocking
[13:58] <LarstiQ> Stavros: yeah, a local change gets me a conflict
[13:58] <Stavros> is that normal?
[13:59] <LarstiQ> I understand why it might happen, it's not ideal.
[14:00] <Stavros> hmm
[14:01] <LarstiQ> Stavros: do you know the revid of the pending merge by chance?
[14:01] <Stavros> it's still in my repo, how do i see it?
[14:01] <LarstiQ> it's unfortunately harder to get to after the fact
[14:01] <LarstiQ> Stavros: `bzr heads` from bzrtools might help
[14:02] <Stavros> hmm, let me install it
[14:02] <LarstiQ> `bzr heads --dead` specifically
[14:03] <LarstiQ> you can then do `bzr pull . -r revid:<bzr heads discovered revid>`
[14:03] <LarstiQ> that will probably give you lots of extra conflicts :/
[14:03] <Stavros> well what good is that then? :P
[14:04] <LarstiQ> Stavros: the revisions are pushed to the master
[14:04] <Stavros> ah
[14:04] <Stavros> with pull?
[14:04] <LarstiQ> Stavros: yup, it's a bound branch
[14:04] <Stavros> oh right
[14:04] <Stavros> sec
[14:05] <Stavros> there are two dead revisions
[14:05] <Stavros> one is five days old
[14:05] <Stavros> wth
[14:06] <LarstiQ> yeah, 'dead' revisions are not garbage collected
[14:06] <Stavros> ah
[14:06] <Stavros> is the other one in my tree?
[14:06] <LarstiQ> lucikly for us, since we can now recover
[14:07] <LarstiQ> Stavros: it is in your repository, but since it is dead not part of your branch history
[14:07] <Stavros> hmm
[14:07] <Stavros> well that's odd
[14:07] <LarstiQ> Stavros: this happens for example when you use uncommit
[14:07] <Stavros> how did the history progress without it?
[14:07] <Stavros> i didn't
[14:07] <LarstiQ> Stavros: or pull --overwrite
[14:07] <LarstiQ> or several other ways possibly
[14:08] <LarstiQ> Stavros: history progressed by backtracking from this branch in the revision DAG and setting off in a different direction
[14:10] <Stavros> ah
[14:10] <Stavros> so what should i do now? pull with the revid?
[14:10] <LarstiQ> Stavros: yes
[14:10] <Stavros> wait, am i pulling from my branch to my branch?
[14:10] <LarstiQ> Stavros: yes
[14:10] <Stavros> should i back up my working tree first?
[14:11] <LarstiQ> Stavros: should not be really needed, but safety first :)
[14:11] <LarstiQ> Stavros: rather than pulling from your branch to your branch, you are pulling from the repository your branch uses
[14:12] <Stavros> the local one, you mean?
[14:12] <Stavros> or the bound one?
[14:12] <LarstiQ> Stavros: the local one
[14:12] <Stavros> ah
[14:12] <Stavros> it's pulling
[14:14] <Stavros> a bunch of conflicts again
[14:14] <Stavros> and my tree is ruined :/
[14:14] <LarstiQ> Stavros: well, you can resolve the conflicts
[14:14] <Stavros> already did
[14:15] <Stavros> but it should be a simple process :/
[14:15] <Stavros> i don't want my dvcs to get in the way like this
[14:15] <LarstiQ> Stavros: agreed.
[14:15] <Stavros> is there another way to do it?
[14:15] <Stavros> maybe unbind and push or just push or something?
[14:15] <LarstiQ> Stavros: unbind and push would have worked.
[14:15] <LarstiQ> Stavros: not having local changes at update time would also not have caused conflicts
[14:16] <LarstiQ> Stavros: personally, I don't use checkouts
[14:16] <LarstiQ> Stavros: longer term, this area needs love
[14:16] <LarstiQ> Stavros: imho, the update should not pivot out the local commits if the master is a strict subset
[14:16] <Stavros> yeah :/
[14:17] <LarstiQ> Stavros: that way it wouldn't need to do any merges, hence no conflicts
[14:17] <Stavros> agreed
[14:17] <Stavros> i use checkouts because i update the master branch every time
[14:17] <LarstiQ> I am very certain this has been discussed in the past, but I can't find a relevant bug atm :/
[14:17] <Stavros> for backup or other workflow purposes
[14:17] <Stavros> hmm :/
[14:18] <LarstiQ> Stavros: maybe you can help me search?
[14:18] <LarstiQ> and then update the bug/try to get some movement on it
[14:18] <Stavros> sure
[14:19] <Stavros> damn, my connection sucks
[14:20] <Stavros> still loading the bugs page
[14:21] <LarstiQ> https://bugs.edge.launchpad.net/bzr/+bug/175589 is not what I had in mind, but it describes your situation
[14:22] <pygi> lifeless, I fixed the problem, just in case you're interested :p
[14:23] <Stavros> i can't load any pages :/
[14:23] <Stavros> my connection is the equivalent of dialup
[14:24] <Stavros> oh wait, it's loading
[14:24] <LarstiQ> Stavros: that sounds painful
[14:24] <Stavros> LarstiQ: it is :/
[14:24] <Stavros> pushes take a minute
[14:24] <Stavros> ah, the page loaded
[14:25] <Stavros> should i comment on that?
[14:26] <LarstiQ> Stavros: I'll comment on it
[14:26] <Stavros> thanks
[14:32] <LarstiQ> Stavros: did I forget anything?
[14:33] <Stavros> i will tell you when it loads :p
[14:34] <Stavros> nope, looks pretty spot on
[14:34]  * LarstiQ subscribed to the bug
[14:35] <LarstiQ> now to file one for `bzr st -v --show-ids`
[14:41] <Stavros> damn, i forgot to subscribe
[14:41] <Stavros> another two minutes of loading
[14:42] <Stavros> pretty multicultural, the subscription list
[14:46] <LarstiQ> Stavros: if needed I can subscribe you
[14:46] <Stavros> i subscribed, thanks
[14:46] <Stavros> it finally loaded
[15:48] <Ileden> Hi! Is there a way to have the .bzr directory in different location of the working tree?
[15:49] <LarstiQ> Ileden: I think the answer is 'no', but I admit that your question isn't entirely clear to me.
[15:50] <Ileden> for example, having tree at /home/ileden/projects/foo/tree-goes-here  and having the .bzr directory for in in /home/ileden/projects/bzrdata/foo/.bzr (or such)
[15:51] <Ileden> I guess one option would be to always have the project files one step deeper, but a custom location would be mor elegant in a way
[15:52] <Ileden> the problem is, I'd like to sync the working tree with Dropbox, which cannot be told how to ignore the .bzr data dir.
[15:54] <Ileden> LarstiQ: yeah, I was afraid it's probably impossible.
[15:55] <Ileden> the underlying problem here is that I'm doing developement on three different computers, and want to keep them in sync
[15:56] <LarstiQ> Ileden: and using the regular publishing methods (bzr push/pull/merge) is not an option?
[15:57] <LarstiQ> (say, you want to sync uncommitted changes as well)
[15:58] <Ileden> yes
[15:59] <Ileden> and if I'm working on three different projects I'd have to throw all my changes to a network place every time I switch computers
[15:59] <Ileden> good scripting might hand that, true, but I still prefer the completely unobtrusive sync Dropbox offers
[15:59] <LarstiQ> does it need to ignore .bzr?
[16:00] <Ileden> I fear it's probably a bad idea to sync the .bzr dir via dropbox.
[16:00] <LarstiQ> `bzr export` also only exports committed revisions, not uncommitted changes
[16:01] <LarstiQ> Ileden: well, a checkout would presumably give you the same style as dropbox
[16:02] <Ileden> LarstiQ: true, but I would lose the ability to make commits independent of network connection
[16:03] <Ileden> which is a real issue, since I do a lot of developement in a disconnected environment (namely, the train :) )
[16:03] <LarstiQ> right
[16:03] <LarstiQ> there is --local, but it has some issues
[16:04] <Ileden> and I also couldn't switch platforms to continue on uncommited changes... athough that's probably not such a big an issue, really.
[16:05] <Ileden> Oh well, placing the files one level deeper than the tree will work fine, just not as elegant, so I think I'll use that.
[16:06] <Ileden> hmm, a bigger problem is of course that I can only apply revision history and commits on one of the computers.
[16:07] <Ileden> ach, it's all just giving me a headache, really :D
[16:08]  * LarstiQ would drop Dropbox
[16:08] <LarstiQ> but that's just me
[16:08] <Ileden> yeah, it's not really a tool for this situation, I know. :-/
[16:09] <Ileden> It's just I love the fact I don't have to do anything to keep the files in sync. Like using a shared online directory, only it's in local path and works offline.
[16:11] <LarstiQ> Ileden: something like the network_manager plugin might help there
[16:12] <Ileden> what are the issues using --local, by the way?
[16:13] <LarstiQ> Ileden: `bzr update` after local will turn your local commits into pending merges, which if there are uncommitted changes will result in spurious conflicts.
[16:15] <Ileden> LarstiQ: Ok. Well, thanks for all the information! I'll try to figure out which would be the best approach for me.
[16:16] <LarstiQ> Ileden: you gave me an interesting idea for changing the network_manager plugin anyway :)
[16:18] <Ileden> :D
[18:22] <goodmami> bzr status says I have a pending merge, but bzr merge says "Nothing to do". any ideas?
[18:23] <Necoro> goodmami: if you have a pending merge, you already merged ... so "bzr merge" won't do anything
[18:23] <Necoro> you need to commit
[18:24] <goodmami> Necoro, thanks. I was confused because my "bzr pull"s were failing and telling me to do a merge
[18:24] <goodmami> i'll try a commit
[18:26] <LarstiQ> goodmami: when pull complains the branches are diverged, you bzr merge; (bzr st; bzr diff, etc to make sure everything is ok); bzr commit
[18:30] <goodmami> LarstiQ, thanks. I committed and pushed fine, and all the code seems in order, but it seems to have erased history of a merge from my other developer
[18:30] <goodmami> (my other developer's changes were the ones i was having trouble merging into my tree)
[18:32] <LarstiQ> goodmami: it sounds like his changes are now merged revisions, and not mainline
[18:32] <LarstiQ> goodmami: does `bzr missing` from his branch to the one you just pushed to claim the revisions are actually missing?
[18:32] <goodmami> LarstiQ, yeah perhaps. The repo is hosted by a launchpad team, of which both he and I are members
[18:32] <LarstiQ> goodmami: also see bzr log --long (and -n0 if using a new enough bzr)
[18:33] <LarstiQ> goodmami: the launchpad web interface doesn't show all revisions, just the mainline ones.
[18:34] <LarstiQ> goodmami: lp:glot?
[18:34] <goodmami> oh ok, i see his messages in the log file. they are under (indented in) my merge
[18:34] <goodmami> LarstiQ, yes
[18:34] <goodmami> launchpad did show his changes until i did the last push, so i figured his were mainline
[18:35] <LarstiQ> goodmami: when you merged his changes and then committed, you reordered the mainline
[18:35] <goodmami> LarstiQ, oh. hm. i guess that can happen, huh.
[18:35] <LarstiQ> goodmami: it can happen. It is indeed not the recommended workflow.
[18:36] <goodmami> LarstiQ, how do I avoid this in the future? should only one person do pushes to the mainline?
[18:37] <LarstiQ> goodmami: the trick is to merge into the trunk, not merge the trunk into your branch and then push it over trunk
[18:37] <LarstiQ> goodmami: say you have ~/src/glot/trunk and ~/src/glot/mami
[18:38] <LarstiQ> goodmami: the first is a mirror of lp:glot, and the second is where you committed your revision 9, then discovered the other Michael had pushed diverging changes to lp:glot
[18:38] <LarstiQ> goodmami: you've now probably done, from ~/src/glot/mami; bzr pull (lp:glot) -> message about divergance; bzr merge; bzr ci; bzr push
[18:39] <LarstiQ> goodmami: if instead of that you did, cd ~/src/glot/trunk; bzr pull; bzr merge ../mami; bzr ci; bzr push; cd ../mami; bzr pull
[18:39] <LarstiQ> goodmami: then his changes would have the same revnos they had (still on the mainline)
[18:40] <goodmami> LarstiQ, I see what you mean, but I was working in trunk (probably not the best idea)
[18:40] <LarstiQ> goodmami: and then your changes would not be shown by the launchpad web interface
[18:40] <goodmami> LarstiQ, I had some changes that i committed, and when i pushed it said I didn't have an up to date tree or something
[18:40] <LarstiQ> goodmami: right
[18:41] <goodmami> LarstiQ, so I think I did a pull and a merge
[18:41]  * LarstiQ nods
[18:41] <LarstiQ> goodmami: there isn't anything technically wrong with how you did things, his changes are still present.
[18:41] <LarstiQ> goodmami: it is just presenting a different view on history.
[18:42] <goodmami> LarstiQ, it said there was something wrong in the file from my other dev, so i tried reverting it, then tried to throw away my changes and only use his
[18:42] <LarstiQ> which I admit us humans aren't always comfortable with
[18:42] <LarstiQ> goodmami: it had a conflict?
[18:42] <goodmami> LarstiQ, great, now I'm a historical revisionist... ;)
[18:42] <LarstiQ> goodmami: only the victors get to rewrite history ;)
[18:42] <goodmami> LarstiQ, it didn't have a conflict, but it complained about it, so I assumed there was a conflict
[18:42] <goodmami> LarstiQ, so... I win?
[18:43] <goodmami> LarstiQ, anyway, I'll be more careful about that now. thanks for the help
[18:43] <LarstiQ> goodmami: in the sense of determing which revisions are the mainline, yes, you just won.
[18:43] <LarstiQ> bzr has an option to disable reordering the mainline, I'm not sure if launchpad can support that too
[18:44] <goodmami> ah
[18:44] <goodmami> LarstiQ, well hopefully we won't come across this again.
[18:44] <LarstiQ> append_revisions_only
[18:44] <goodmami> thanks
[18:44] <LarstiQ> (dredged up from `bzr help configuration`)
[18:45] <goodmami> ooh, i'll go check that out
[18:45] <LarstiQ> goodmami: please do :)
[18:45] <LarstiQ> feedback welcome
[18:45] <goodmami> sure
[18:45] <goodmami> thanks again
[20:19] <stbuehler> what does it mean when i get "conflicting tags" in a "bzr push" to a svn repository (we migrated to a new server, 32 -> 64 bit) ?
[20:22] <LarstiQ> no other changes to the svn repo?
[20:22] <LarstiQ> no editing of the tags on the bzr side?
[20:31] <stbuehler> i don't know for sure, but i don't thinks o
[20:33] <LarstiQ> stbuehler: then my ideas are depleted and you'll have to ask jelmer
[20:33] <stbuehler> any simpler way restoring this than rebranching it? i do not really care about my bzr history, i use bzr just as a frontend to svn
[20:34] <LarstiQ> stbuehler: does the push actually fail, or is it just a message? I suspect the latter.
[20:35] <stbuehler> just a message
[20:35] <stbuehler> but i don't like it :)
[20:37] <LarstiQ> stbuehler: does it repeat on later pushes?
[20:37] <LarstiQ> stbuehler: and yes, it should go away after rebranching
[20:37] <stbuehler> yes
[20:38] <LarstiQ> stbuehler: I'm not too well versed in tags, but if you can find out what (bzr-)svn thinks the tags are, you could edit the tags file by hand
[20:47] <stbuehler> i deleted some tags and pushed again -> no warning for them. bzr pull, tags reappeared, and with the next push the warning came back
[20:51] <LarstiQ> stbuehler: ok. Have you looked through open bzr(-svn) bugs on tags?
[21:03] <gotgenes> I'm trying to install bzr to my home directory on a red hat machine; I got the error "ImportError: No module named _md5" What's supposed to provide that module?
[21:03] <LarstiQ> gotgenes: what version of python and bzr are you using?
[21:03] <gotgenes> looks like python 2.5.1 installed to /usr/local
[21:04] <gotgenes> bzr 1.13.1 from source
[21:04] <LarstiQ> gotgenes: can you pastebin the backtrace?
[21:04] <gotgenes> LarstiQ: Sure
[21:04] <gotgenes> one sec
[21:04] <LarstiQ> gotgenes: note that you can run bzr from source, no installation needed
[21:05] <LarstiQ> (running make is still a good idea for more performance)
[21:06] <gotgenes> LarstiQ: http://rafb.net/p/yXkGrD79.html
[21:07] <LarstiQ> gotgenes: that looks like your python install is broken.
[21:08] <LarstiQ> gotgenes: or at the very least doesn't contain the modules one expects from stdlib.
[21:08] <LarstiQ> gotgenes: is this a python2.5-minimal package or somesuch?
[21:08] <gotgenes> LarstiQ: Possibly. I'm not the sysadmin for that box, unfortunately.
[21:08] <gotgenes> LarstiQ: Quite likely.
[21:08] <gotgenes> Supposedly it was downloaded from source.
[21:11] <LarstiQ> gotgenes: python -c 'from hashlib import md5' breaks, right? Does python -c 'import md5' fail as well?
[21:11] <gotgenes> LarstiQ: Yes, I just ran that.
[21:11] <LarstiQ> gotgenes: if so, I'd bug the admin asking for a working python install.
[21:12] <gotgenes> LarstiQ: It seems I'll need to.
[21:12] <LarstiQ> gotgenes: bzr does really need that to operate, is installing your own copy of python an option in the mean time?
[21:12] <gotgenes> LarstiQ: Sure, into my home directory
[21:12] <gotgenes> Suppose that's not too hard to do
[21:43] <gotgenes> LarstiQ: installed Python to the home dir and bazaar installed fine after
[21:45] <LarstiQ> gotgenes: cool
[21:47] <gotgenes> Thanks for your help.
[23:54] <jml> hello
[23:55] <jml> I was looking at bug 351686, and wondering whether it's even possible with Bazaar
[23:58] <lifeless> small matter of code
[23:58] <lifeless> -p is actually a regex search up from the change region
[23:59] <lifeless> we support external diff options too if you're invoking diff
[23:59] <jml> cool.