=== bob2 is now known as Guest19481 [00:47] bzr diff ../server/e/HEAD/ -c 64 | patch -p0 [00:47] why does that work, yet bzr merge is too stupid to handle it? :/ [00:49] fuzz 2? [00:50] luke-jr: Answering that would requrire the message bzr gives as the reason it can't merge. [00:50] it just does conflicts galore [00:51] I'm merging lp:moo/lambdamoo-1.8 updates into lp:~luke-jr/moo/db_options [00:56] Hm. Not really sure. [01:06] luke-jr: does it detect a criss-cross merge? [01:06] lifeless: there is no criss-cross, no [01:07] db_options has and never will be merged into lambdamoo [01:09] luke-jr: its odd that it is conflicting [01:10] what type of conflicts is it giving? [01:10] the MERGE-SOURCE side is trying to add about 500 lines of code that was removed in the branch [01:12] you could try --weave [01:12] haha. no. [01:13] weave is evil [01:15] 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] correct [01:16] trunk is a CVS import, if that is at all relevant [01:16] branch was created from a tag in the bzr import [01:22] I need to manipulate file-ids. Any advice? [01:28] why do you need to do that? [01:29] telling Bazaar about a rename [01:29] 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] long after the fact [01:29] bzr mv --after [01:29] it wasn't [01:29] lifeless: long after, meaning the commit is 50 revisions ago [01:29] re the conflicts - in which case please file a bug [01:29] luke-jr: bzr rm foo --keep; bzr add --file-ids-from [place that has the file] foo [01:30] luke-jr: also --weave isn't evil, its good - mysql use it all the time to get massively less conflicts [01:30] hmm [01:30] --weave reduces conflicts, sure, but often it duplicates code [01:31] does it? I haven't seen that. That would be a bug IMO [01:31] O.o [01:31] basically, feel free to file bugs on merge logic [01:31] some will be things we can't easily fix without throwing other things out [01:31] but there is lots of room to improve [01:32] the problem-causing merges seem to trigger patch to say "with fuzz 2" [01:32] I can only presume that's related [01:35] getting only 8kB from LP everything else fast [01:37] lifeless: any way I can ensure I'm not about to totally screw up my branch? XD [01:37] bzr status is giving me some funky output ;/ [01:37] added: db_objects.c [01:38] renamed: db_objects.c => db_save_objects.c [01:38] modified: db_save_objects.c [01:38] does that make sense? :/ [01:39] sure [01:39] it says that db_objects was modified and renamed [01:39] and that you have added a new fiel db_objects.c [01:39] ok [01:40] sigh [01:40] trying to tie these merge trees together is a pain === Guest19481 is now known as bob2 [04:43] how do i get my working tree into where it was before 9841 was committed? [04:43] bzr revert -r9840 [04:43] oh [04:43] Or.. more accurately, something like bzr revert -rparent:9841 but that probably comes down to 9840 anyway [04:43] i thought revert was only for reverting changes since last commit. [04:43] my bad. [04:44] revert puts it back to the state at some commit.. by default the most recent... but -r can pick a different one [04:55] what does -rparent do for merges? :p [04:57] Hmm, it's "before:", and the help doesn't say. [04:59] can i reload my bzr.conf file? [05:00] i've made an edit but the changes don't seem to take effect [05:03] bzr.conf? [05:03] sorry branch.conf [05:08] The changes don't take effect...where? There's nothing to reload [05:09] well i defined the alias from the tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html [05:10] but if i try something like 'bzr ll' i get an unknown command error [05:10] i thought i might have to run some sort of source command, the way i do when i edit .bashrc or something [05:12] vinc456: Maybe you have to set that in ~/.bazaar/bazaar.conf. [05:15] Peng_: i set ~/.bzr/branch/branch.conf [05:16] anyways it's not a big deal [05:16] it'll probably work fine once the next time i reboot [05:16] vinc456: Um, no it won't. [05:16] vinc456: ~/.bazaar/bazaar.conf. [05:19] Peng_: ah ok, i was confused [05:19] thanks [05:45] does cherrypicking lose merge tracking? [05:46] 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] that's on bzr 1.11 [05:48] seb_kuzminsky: That's correct. Which is why we try to avoid cherrypicking. :D [05:55] ok thanks Peng [05:56] Sorry. :\ [06:00] make check-dist-tarball failing on 1.14rc1 release. Anyone able to look at bug 355454 ? [06:00] Launchpad bug 355454 in bzr "$ make check-dist-tarball failure" [Undecided,New] https://launchpad.net/bugs/355454 [06:01] I don't think Unicode issues like that are new. [06:02] wasn't an issue 1.13 [06:03] Oh. Never mind then. :D [06:10] interesting bzr selftest passes [06:13] make check tests with multiple LANG values. [06:13] So it's more likely to expose Unicode bugs than just selftest. [06:17] Ahh, how it make through PQM? I thought the multiple LANG stuff got put into PQM? [06:18] * Peng_ shrugs [06:19] less shrugs, more answer! :-P [06:21] make check runs with your normal locale and the standard C locale. I'm not sure what PQM does. [06:22] Maybe your specific locale exposes some bug that PQM's setup doesn't. [06:22] That's about all the answer I have. === chx is now known as chx_sleeping [06:57] 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 " rather than "Glyph Lefkowitz " [06:57] Is there a way I can fix up that history? [06:59] Pretty much no. [07:00] Peng_: Hmm... I guess I should rebase from zero then? [07:00] 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] glyph: editing a fast-import dump might be relatively painless, if you really care. (does it really matter?) [07:03] 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] glyph: I trust GPG signed commits as a verification method much more than an email address. [07:47] jkakar: These commits weren't signed either :) [07:47] jkakar: Can I go back and sign them? [07:48] bzr sign-my-commits [07:56] bob2: Huh [07:56] and then if I push somewhere, signatures for old revisions will be published? [07:56] dunno [07:56] also not sure what it'll do wrt your whoami having changed - you might need to temporarily change that back [07:57] bob2: It looks like I can pass a committer on the commandline [08:09] 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] glyph: and possibly a hidden command [08:10] I guess for now I will not worry about this [09:01] 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] jkakar: I'll be adding something like that soon, as soon as I figure out how seahorse-agent works [09:02] (I don't like having gpg private keys on my hard drive) [09:02] Yeah, that's probably a good call. [09:02] I was doing the SSH+GPG key on a USB stick thing for a while... [09:03] jkakar: You stopped? [09:03] ok, folks, got a tiny problem with push [09:03] 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] http://slexy.org/view/s21qWJI3Rj [09:04] 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] glyph: So yeah, I stopped. [09:04] I'm probably not paranoid enough, oh well. Ignorance really is bliss. ;) [09:05] How would I go about undoing a "bzr add"? [09:05] : ) [09:05] [ removing all of the files that were added b/c of that command.. ] [09:06] kizzo: rm `bzr added` [09:06] kizzo: or 'bzr revert' the added files [09:06] jkakar: That looks like it would actually delete the files from my disk, huh? [09:07] The first one. [09:07] kizzo: It will, yes. [09:07] Oh ok, so revert is probably what I would like to happen then. [09:07] Cool. [09:08] Thanks. [09:09] :-/ [09:10] py whats wrong? [09:10] pygi: ^ [09:11] lifeless, If I knew that'd be good :p [09:11] probably something with the server :P [09:11] lifeless, http://slexy.org/view/s21qWJI3Rj [09:11] oh, I can't browse right now [09:13] :P [09:13] basically, I can't push :D [09:13] do you get an error? [09:13] bzr: ERROR: bzrlib.errors.ErrorFromSmartServer: Error received from smart server: ('error', 'Operation not supported: open_write_stream') [09:13] that sounds like you have an _extremely_ old server [09:13] or hmm [09:13] perhaps its backed onto a readonly transport [09:14] the latter is more likely I think [09:14] * pygi is pretty sure he configured rw privs [09:15] it might be that security subsystem of this server is a bit wonky [09:15] its still pretty fresh [09:15] are you pushing to bzr+ssh/bzr/bzr+http? [09:15] bzr+http [09:15] what backing transport did you give it in your glue code? [09:16] hmm [09:16] how do you mean? [09:17] well to setup a bzr+http server you need some wsgi glue [09:18] and in that you tell it where the server backend is [09:18] what url did you use in there [09:18] yup, moment :p [09:19] local_url = wsgi.local_path_to_url(root) ? [09:20] I mean, I can branch pretty fine, its probably something in the security code or something :-/ [09:20] no [09:21] (not of bzr security code, but of that wsgi glue/security glue code that you say :) [09:22] did you follow the howto ? [09:22] doc/en/user-guide/http_smart_server.txt [09:23] actually, no, purely because I use a custom-written server (clue-bzrsever) [09:23] ok [09:23] well [09:23] cross reference the howto [09:23] if when you start the backend server you are passing in an http transport its fundamentally wrong [09:24] from bzrlib.transport.http import wsgi [09:24] smart_server_app = wsgi.make_app( [09:24] root='/srv/example.com/www/code', [09:24] prefix='/code/', [09:24] path_var='REQUEST_URI', [09:24] readonly=True, [09:24] load_plugins=True, [09:24] enable_logging=True) [09:24] is the key bit [09:24] root needs to be your on disk path to the root you want to serve out [09:24] and you'll want readonly=False :) [09:24] :) [09:26] thanks, I'll see what I can do [09:29] hm, ok, readonly IS false [09:30] is this correct: write = ['mkdir', 'put_file', 'delete', 'rename', 'rmdir', 'append_file', ] ? [09:30] that looks like something to do with your custom server [09:30] its certainly not an accurate list of what bzr uses to push, if thats what you're asking [09:30] can that be the problem? [09:32] I don't know, I'm guessing at things here [09:32] what does this custom server do? [09:32] how does it hook into bzr? [09:32] using bzrlib [09:33] 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] I have no idea about it, today is the first time I heard of it [09:34] and without knowing a fair bit more I can't offer good advice :( [09:34] let me check [09:35] 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] in which case giving it a more complete list would be a good idea:) [09:36] could you point me to location where I can find more complete list? :) [09:36] pydoc bzrlib.transport.Transport is the base class for all transports [09:36] it defines the public api [09:38] pygi: what does the custom server do for you? [09:39] serves bzr directories (repos) and handles security [09:39] it seems to define its own ACLTransport ...(or well, at least it has such a class :P) [09:42] (bzr 1.13.1, if it makes any difference) [09:42] yes, they probably didn't implement the entire contract, only what they saw used [09:42] bzr 1.13 streams [09:42] which means the server will use the streaming transport apis [09:43] hm, can that be the problem then? I mean I doubt this was written with 1.13 in mind... [09:44] (and yes, I know I'm bugging, sorry :)) [09:44] I assume so [09:45] * pygi goes try with different bzr [09:45] guess I'll just have to submit patches if that's the problem:) [09:48] it seems to need 1.12... [09:48] * pygi tries that [09:55] lifeless, ok, different problem: bzr: ERROR: Server sent an unexpected error: ('error', 'Operation not supported: append_file') [09:55] o.O [10:01] pygi: have you used this software before :) - [is it complete :P] [10:01] lifeless, actually, this is the first time I'm testing it thoroughly :P [10:01] but it is supposed to be complete :p [10:06] don't worry about it, I'll look into the codebase :) [10:06] thanks for all the help [10:07] np === NEBAP|work2 is now known as Nebap|work === Nebap|work is now known as NEBAP|work [10:57] http://www.pastie.org/437377 [10:57] guys [10:57] guys I was trying to understand this error. can someone help? [10:58] http://www.pastie.org/437377 [10:58] Basically want to get rid of everything in the dir and get a fresh new copy from bzr repository [10:59] can someone please help? :) [11:04] bzr break-lock file:///home/dchoon/dcrepo/ [11:04] 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] Peng_: Yeah I just ran the bzr break-lock [11:05] it worked [11:05] but then I did the "bzr pull --overwrite" [11:05] and it still kept all the rest of the files in there [11:05] Uh-huh...? [11:05] What files? [11:05] so you deleted some files [11:05] and want them back? [11:06] ala 'xvs update'? [11:06] well basically this developer added new files etc... and his version doesn't work [11:06] so I suggested overwriting all his local files [11:06] that's not an awesome idea [11:07] well basically want to revert back to what was working well... [11:07] he has gone ahead and created all these files and ran commands that blurted out lots of stuff that isn't needed [11:07] its easier for him to checkout the latest repo copy and start from there [11:07] so, 'bzr revert' will revert to the last commited version [11:08] yeah but it might still keep the new stuff? [11:08] he has not ADDED his new files [11:08] then delete them [11:08] pull isn't going to delete random un-added files from the working tree [11:08] bzr revert ; bzr clean-tree # revert and delete all unadded files [11:11] says unknown command [11:11] it's new [11:11] clean-tree is an unkown command [11:11] alternatively, 'bzr status' then manually delete the files [11:11] got an older equivalent [11:11] or branch from your repository again [11:12] how bout add and then revert? [11:12] would that not add all the new files in and then when you revert it gets rid of them all? [11:17] CBro2007: clean-tree used to be in bzrtools before it moved to bzr core [11:17] ok [11:17] bzr ls --unknown | xargs rm [11:18] would also work [11:18] as long as there are no spaces in your filenames [11:18] and no directories, but you get the idea [11:20] thanks bob2 [11:21] thats all good now [11:21] just a normal delete and then a revert === chx_sleeping is now known as chx [13:32] why does bzr insist on messing up my tree when all i want to do is push my local changes upstream? [13:33] it is interfering with the whole "distributed" paradigm [13:34] can i just push instead of updating on a bound branch? [13:36] Stavros, yes, but you have to use branches instead of checkouts [13:36] you can use --reconfigure to change a checkout into a branch [13:37] 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] Stavros: eh? [13:37] i just want to push the changes, how can i do that? [13:37] Stavros: could you be more specific as to what happens? [13:37] LarstiQ: i have a bound branch [13:37] i commit with --local [13:37] then i update, and my local working directory gets messed up [13:38] please describe 'messed up' a bit more. [13:38] LarstiQ: he doesn't want the merge implied by update [13:38] bzr thinks there are conflicts, but the revision on the remote repo is one earlier than the local one [13:38] Stavros: that is weird [13:38] so the remote has rev 60, the local rev 61, and it still merges [13:38] Stavros: why are you doing update? why not just commit? [13:39] james_w: i did commit once [13:39] james_w: don't i have to update to push them? [13:39] Stavros: are they the same revision though? [13:39] LarstiQ: the local repo has one more revision [13:39] Stavros: I don't think so [13:39] LarstiQ: i'm the only person working on this, so they never diverge [13:39] james_w: hmm [13:39] Stavros: you do update to merge in changes from the master branch [13:40] Stavros: hah, I diverge myself pretty often, but ok :) [13:40] LarstiQ: sure, but isn't bzr supposed to know that there haven't been any? [13:40] now, it tries to sort of "revert" to the master branch [13:40] and gives me conflicts to what i changed [13:40] Stavros: indeed, so I'm rather suprsised at conflicts. [13:40] LarstiQ: well yes, but i don't atm :p [13:40] now i have a pending commit, how do i push it upstream? [13:40] Stavros: commit. [13:40] with a message again? [13:41] i don't want to commit my local changes, though [13:41] Stavros: yes, or you can be sneaky. [13:41] hmm [13:41] Stavros: and bzr pull . -r revid:revidoflocaltip [13:42] Stavros: it does sound like maybe a checkout is not the optimal workflow for you though. [13:42] i just want to do the equivalent of a push but on a bound branch :/ [13:42] LarstiQ: why not? [13:42] (apart from update pivoting changes when not strictly needed) [13:42] LarstiQ: i don't want to push each time by hand, so a checkout suits me better [13:43] Stavros: judging from this one case, but maybe the rest of what you do suits better [13:43] Stavros: right, ok [13:43] Stavros: let me mock something up and test if that would work for you [13:43] so what's the best way to just push my changes? [13:43] thanks [13:46] LarstiQ: can you reproduce the update merge, by the way? [13:47] Stavros: the update merge is normal, but it doesn't produce any conflicts for me [13:47] hmm [13:48] 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] Stavros: I'll find you a relevant bug report about the pending merges pivot first [13:49] hmm ok [13:49] so it goes, bzr ci, bzr ci --local, change line, bzr up, conflicts [13:50] 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] ah [13:53] hmkay, can't find it from bug titles, back to mocking [13:58] Stavros: yeah, a local change gets me a conflict [13:58] is that normal? [13:59] I understand why it might happen, it's not ideal. [14:00] hmm [14:01] Stavros: do you know the revid of the pending merge by chance? [14:01] it's still in my repo, how do i see it? [14:01] it's unfortunately harder to get to after the fact [14:01] Stavros: `bzr heads` from bzrtools might help [14:02] hmm, let me install it [14:02] `bzr heads --dead` specifically [14:03] you can then do `bzr pull . -r revid:` [14:03] that will probably give you lots of extra conflicts :/ [14:03] well what good is that then? :P [14:04] Stavros: the revisions are pushed to the master [14:04] ah [14:04] with pull? [14:04] Stavros: yup, it's a bound branch [14:04] oh right [14:04] sec [14:05] there are two dead revisions [14:05] one is five days old [14:05] wth [14:06] yeah, 'dead' revisions are not garbage collected [14:06] ah [14:06] is the other one in my tree? [14:06] lucikly for us, since we can now recover [14:07] Stavros: it is in your repository, but since it is dead not part of your branch history [14:07] hmm [14:07] well that's odd [14:07] Stavros: this happens for example when you use uncommit [14:07] how did the history progress without it? [14:07] i didn't [14:07] Stavros: or pull --overwrite [14:07] or several other ways possibly [14:08] Stavros: history progressed by backtracking from this branch in the revision DAG and setting off in a different direction [14:10] ah [14:10] so what should i do now? pull with the revid? [14:10] Stavros: yes [14:10] wait, am i pulling from my branch to my branch? [14:10] Stavros: yes [14:10] should i back up my working tree first? [14:11] Stavros: should not be really needed, but safety first :) [14:11] Stavros: rather than pulling from your branch to your branch, you are pulling from the repository your branch uses [14:12] the local one, you mean? [14:12] or the bound one? [14:12] Stavros: the local one [14:12] ah [14:12] it's pulling [14:14] a bunch of conflicts again [14:14] and my tree is ruined :/ [14:14] Stavros: well, you can resolve the conflicts [14:14] already did [14:15] but it should be a simple process :/ [14:15] i don't want my dvcs to get in the way like this [14:15] Stavros: agreed. [14:15] is there another way to do it? [14:15] maybe unbind and push or just push or something? [14:15] Stavros: unbind and push would have worked. [14:15] Stavros: not having local changes at update time would also not have caused conflicts [14:16] Stavros: personally, I don't use checkouts [14:16] Stavros: longer term, this area needs love [14:16] Stavros: imho, the update should not pivot out the local commits if the master is a strict subset [14:16] yeah :/ [14:17] Stavros: that way it wouldn't need to do any merges, hence no conflicts [14:17] agreed [14:17]