| lifeless | vila: still up? | 00:00 |
|---|---|---|
| PureRumble | greetings, newb here failing to properly setup bazaar server on localhost. | 00:25 |
| PureRumble | This is what I do to setup bazaar server: "sudo bzr serve --directory=files/servers/bazaar/ --bzr" | 00:26 |
| lifeless | you probably don't want the server running as root | 00:26 |
| PureRumble | See... I'm that bad. :-) | 00:26 |
| PureRumble | I mean bad as in notknowing. | 00:26 |
| spiv | PureRumble: I agree with lifeless, but that command should still work | 00:27 |
| PureRumble | Ok, so I will not run as sudo. bad idea. bad idea! :-] | 00:27 |
| PureRumble | Ok but there are still problems. So now I no longer run server as root. | 00:29 |
| spiv | PureRumble: what problems? What error are you getting? | 00:30 |
| PureRumble | But still when I do "bzr push bzr://localhost/test" I get "bzr: ERROR: Transport operation not possible: readonly transport" | 00:30 |
| spiv | PureRumble: right | 00:30 |
| spiv | PureRumble: you need to explicitly pass --allow-writes to bzr serve if you want to allow that | 00:30 |
| PureRumble | see, it's that easy! :-) | 00:31 |
| spiv | PureRumble: (in which case it's a really good idea not to run it as root!) | 00:31 |
| spiv | PureRumble: you may want to create a user on your system just for bzr serve | 00:32 |
| PureRumble | Ok, I have now created my first branch! But right now anyone can connect to my server from the web (if it wasn't for ufw), right? | 00:32 |
| spiv | PureRumble: connect, and write to! | 00:32 |
| spiv | PureRumble: Why do you want to run a server? | 00:33 |
| PureRumble | ok, so something tells me that is not good and needs to be taken care of :) | 00:33 |
| spiv | You don't need one to create branches. | 00:33 |
| PureRumble | Because, I thought it would be better than storing stuff in .bzr folders, but perhaps I'm wrong? | 00:33 |
| spiv | You don't need a bzr server for that. | 00:33 |
| spiv | If it's just you, locally, don't bother with bzr serve. | 00:34 |
| spiv | Just run bzr directly. | 00:34 |
| PureRumble | But then stuff would be stored in .bzr-folders, is that a good idea? *non-rethorical question* | 00:34 |
| spiv | e.g. instead of "bzr push bzr://localhost/test", you can do "bzr push files/servers/bazaar/test" | 00:34 |
| spiv | I'm not sure what you mean by .bzr folders. | 00:35 |
| rockstar | How can I find out what revision a file in my tree was last changed? | 00:35 |
| rockstar | I thought blame would do it, but that seems to be an alias for annotate | 00:35 |
| bob2 | bzr log -l1 filename ? | 00:35 |
| rockstar | bob2, yeah, after typing that, I had to wonder if log would take a file as an argument, so I went to look. | 00:36 |
| rockstar | bob2, cheers though. | 00:36 |
| bob2 | ahh | 00:36 |
| spiv | PureRumble: I think maybe you're talking about the difference between a treeless branch and branch with a colocated working tree. | 00:37 |
| idnar | is it possible to uncommit a revision that isn't the tip? | 00:38 |
| idnar | actually, nevermind, I don't think I want to do that | 00:38 |
| spiv | PureRumble: bzr doesn't really care either way; the full history is still stored. If you want to make treeless branches directly then you can use e.g. "bzr branch --no-tree" or even better make a shared repository for your branches with "bzr init-repo --no-trees" | 00:39 |
| spiv | idnar: good, because you can't (without also uncommitting the revisions between it and tip) | 00:39 |
| PureRumble | I'll be honest and say my revision-controlling knowledge is not the best. I thought I would setup a bazaar server on my computer so I can manage code from anywhere. | 00:40 |
| spiv | idnar: you can reverse the changes made by a particular revision, though. | 00:40 |
| spiv | (and commit that) | 00:40 |
| spiv | PureRumble: you can access bzr branches via SFTP and SSH | 00:40 |
| spiv | PureRumble: you don't need a special bzr server to do that, just allow SSH access. | 00:40 |
| idnar | spiv: that causes problems if you want to put the changes back later | 00:42 |
| PureRumble | Ok, so having done bzr init, add and commit for some branch, how can I modify it from another host without setting up server? | 00:42 |
| spiv | idnar: no more than the reversing | 00:42 |
| lifeless | PureRumble: the most secure way is via bzr+ssh | 00:44 |
| idnar | https://bugs.edge.launchpad.net/bzr/+bug/152008 | 00:44 |
| ubottu | Launchpad bug 152008 in bzr "Ability to unmerge or revert a merge sensibly" [Wishlist,Triaged] | 00:44 |
| spiv | idnar: I'm talking about a cherrypick merge; e.g. "bzr merge . -r 99..98 && bzr ci -m 'Undo r99'" | 00:44 |
| lifeless | PureRumble: install opensshd | 00:44 |
| idnar | I believe that bug covers what I'm talking about | 00:44 |
| spiv | idnar: right, including the merge . -r <backwards-revision-range> recipe. | 00:46 |
| PureRumble | ... Ahaaaa, so you mean I should connect through opensshd and just navigate to the same dir and continue working? | 00:47 |
| mmj8237 | Hello, I did a bzr push before to a new location and noticed that it created a working tree at the new location when I didn't expect it to - is there an option for bzr push that prevents creating a working tree in the new location? | 00:47 |
| bob2 | that's the default | 00:48 |
| chx | what happens if someone runs a bzr up on a checkout and someone else does a bzr uncommit...? the uncommitted changes disappear on next up? | 00:49 |
| mmj8237 | The documentation may be out of date, or maybe I have read it wrong, but I thought that bzr push wasn't supposed to update/create the remote working tree | 00:49 |
| spiv | PureRumble: you can do that, but you can also use commands like "bzr branch bzr+ssh://yourhost/path/to/your/branch" | 00:49 |
| lifeless | mmj8237: you pushed to a file:/// url | 00:50 |
| spiv | mmj8237: "remote" in that context just means "connected via a network URL than a local file path" | 00:51 |
| lifeless | mmj8237: they aren't 'remote' | 00:51 |
| mmj8237 | lifeless: yes it was a file:// url, though it was a mapped network drive with a kind of low disk space quota and I didn't expect a working tree... | 00:51 |
| spiv | mmj8237: If it's a one-off, you can just remove the branch afterwards with the "bzr remove-tree" command. If you're going to push several of these, maybe you want a shared repository made with "bzr init-repo --no-trees" | 00:52 |
| PureRumble | ok so I'll install openssh-server... but will I need the client too? | 00:52 |
| spiv | PureRumble: only if you need to connect to the server ;) | 00:53 |
| mmj8237 | spiv: thanks for your help. Yep bzr remove-tree works, just wondering if there was another command, but it seems like there isn't. Chosen not to use a shared repo for various reasons. | 00:53 |
| PureRumble | I'm not very good at this, no not at all :-/ | 00:53 |
| spiv | mmj8237: yeah, we should probably add --no-tree to 'bzr push', 'bzr branch' had that added relatively recently. | 00:54 |
| mmj8237 | cool | 00:54 |
| spiv | mmj8237: I'm a bit surprised that a shared repo isn't suitable given that you're concerned about disk space, but ok. | 00:54 |
| spiv | mmj8237: file a bug? :) | 00:54 |
| mmj8237 | spiv: I am using stacked branches rather than a shared repo, I figure that if I delete a branch off that server it allows me to recover the disk space more easily than with a shared repo. | 00:55 |
| mmj8237 | Though if you had other suggestions I'd be all ears :) | 00:56 |
| spiv | mmj8237: ah ok, interesting. I would expect with most workflows that a shared repo would still be smaller than a collection of stacked branches. | 00:57 |
| lifeless | poolie: http://rproxy.samba.org/ has a stale link to http://samba.org/~mbp/superlifter/ | 00:58 |
| spiv | mmj8237: because stacked branches inherently have a little bit of duplication with the repo they are stacked on, plus merges between them will require copying revisions around rather than just having one copy. | 00:58 |
| PureRumble | So if the branch's absolute path is /home/foo/bar, do I do "bzr diff bzr+ssh://localhost/home/foo/bar" ? | 00:58 |
| spiv | mmj8237: but I guess it depends on how much being able to completely delete unwanted revisions can save you space. | 00:59 |
| lifeless | PureRumble: typically no | 00:59 |
| lifeless | PureRumble: you generally only diff locally - 'bzr diff' | 00:59 |
| PureRumble | ok but that was just an example. | 00:59 |
| lifeless | PureRumble: but that url is correct | 00:59 |
| PureRumble | Ok, it actually works! But a bit annoying to print the password each time I wanna do something.... :-/ | 01:02 |
| lifeless | PureRumble: you can use an agent to remember the password or passphrase (if you use ssh keys) | 01:03 |
| mmj8237 | After a quick bug search I filed a request for --no-tree on bzr push at https://bugs.launchpad.net/bzr/+bug/506730 - hope this is ok thx | 01:06 |
| ubottu | Launchpad bug 506730 in bzr "Add --no-tree to bzr push" [Undecided,New] | 01:06 |
| spiv | mmj8237: thank you! | 01:07 |
| PureRumble | Ok thanks, so now things seam to be working smoothly. | 01:08 |
| PureRumble | But how can I restrict what users can connect to my bzr server if I want to have such a server? | 01:09 |
| lifeless | the plain bzr:// protocol doesn't have authentication or access control | 01:09 |
| lifeless | if you need that, use bzr+ssh or bzr+http | 01:09 |
| PureRumble | ok, but how does say launchpad work? They restrict who connects and gets to see the code, right? And they use bazaar servers, right? | 01:11 |
| spiv | PureRumble: in your situation I'd just provide access via SSH, and then only users that can connect are the ones I've created accounts on my system for. | 01:11 |
| lifeless | they use bzr+ssh | 01:11 |
| spiv | PureRumble: and if you want to limit which of those users can read/write particular things, I'd use regular filesystem permissions to control that. | 01:12 |
| PureRumble | spiv: but that would be a problem if the files happen to be on ntfs, right? | 01:13 |
| spiv | PureRumble: I wouldn't think so, ntfs has file permissions too. | 01:15 |
| spiv | ACLs even! :) | 01:15 |
| spiv | (But I don't have much experience with managing ntfs from linux) | 01:17 |
| PureRumble | yeah i knew that, i'm not that bad :-(. Just didn't think linux can modify them. | 01:17 |
| PureRumble | General question: what do you suggest for managing php project (with revision control) remotely? | 01:19 |
| PureRumble | I can set up apache on my host to connect remotely and test my code... but how can I work remotely on my code with revision control? | 01:22 |
| spiv | PureRumble: maybe the bzr-upload plugin or the bzr-push-and-update plugin would help. | 01:22 |
| PureRumble | Ok so bzr+ssh to retrieve files and modify and the upload back... but how to do build commands, such as ant, remotely? | 01:27 |
| PureRumble | Pardon newbie questions. | 01:27 |
| RAOF | Well, you could do that with ssh. | 01:35 |
| RAOF | I'd also expect it to be relatively easy to write a server-side bzr plugin that ran your buildsystem for every commit. | 01:35 |
| lifeless | or use e.g. hudson | 01:36 |
| PureRumble | so much knowledge outside my brain, so little inside it! googling hudson | 01:37 |
| lifeless | hudson-ci.org | 01:37 |
| lifeless | PureRumble: thats for doing build testing | 01:38 |
| lifeless | PureRumble: if you want deployment tools, you probably want to ssh into the server and then do a bzr pull; ant build (or other sequence of commands) | 01:39 |
| PureRumble | Ok some other general questions if I may: if I have hostA and another hostB, can I somehow map /foo/magic on hostA to /bar/magic on hostB safely through ssh? That would make things easy! | 01:49 |
| PureRumble | hostA and hostB different computers connected to web. | 01:49 |
| jacseen | I've run into a merge issue with bzr 1.16, a new branch on launchpad is listed on lp: as format 7, but bzr lists it as unknown. How do I upgrade my old branches so that htey can be merged into a local copy of version 7? My other branches are 'pack-0.92' and lp: calles them version 6. | 01:51 |
| PureRumble | So like if I write some file to /foo/magic, ssh makes sure it is written remotely to /bar/magic on hostB. | 01:51 |
| RAOF | jacseen: “bzr upgrade” your branches. You can do this on your local branches, and also remotely (“bzr upgrade lp:my-project” will work, but slowly). | 01:52 |
| RAOF | PureRumble: You can do that (at least in linux), but why do you want to? | 01:53 |
| PureRumble | So I can easily manage stuff remotely of course :-) | 01:53 |
| chx | RAOF: Fuse (hence sshfs) exists for BSD too :p | 01:54 |
| PureRumble | Look, I have my computer here at home and sometimes do coding on it. But sometimes I want to continue code on the same project but on my laptop. | 01:54 |
| RAOF | chx: And I think MacFUSE exists, too :P | 01:54 |
| chx | RAOF: not to mention the opensolaris port. | 01:54 |
| jacseen | RAOF, just a noob question, how does bzr know what format to upgrade my 'pack-0.92' branches too? It doesn't even recognize the format of the version 7's as reported by launchpad? | 01:55 |
| RAOF | jacseen: Bah. Sorry, I should have read your question more thoroghly. | 01:55 |
| AfC | jacseen: also, if you can upgrade to bzr >= 2.0 you'll find things work faster. | 01:55 |
| chx | and Dokan on Windows. | 01:55 |
| PureRumble | So that's pretty much my problem. I have a php project on my main computer, but sometimes I wanna work from my laptop... all in all without duplicate code of course! | 01:56 |
| mac9416 | AfC, how does one upgrade to bzr 2.0 in, say, Ubuntu 9.10? | 01:56 |
| RAOF | PureRumble: ssh will do that, but I'm not sure why you're hung up on the “without duplicate code”. I'd just have a branch on the main computer, and a branch on the laptop. | 01:56 |
| AfC | mac9416: use the bzr PPA | 01:57 |
| lifeless | jacseen: I think you need a newer version of bzr | 01:57 |
| AfC | deb http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main | 01:57 |
| mac9416 | AfC, gracias. | 01:57 |
| AfC | that has the latest stable release. | 01:57 |
| PureRumble | RAOF: Help a guy that has been haunted by this for a while now and wanna sleep. :-( Say I've done bzr init, add & commit on some folder on main computer. That starts the branch there, right? I've also enabled ssh on it. Good. | 01:59 |
| jacseen | AFAIK bzr 2.0+ uses a different default branch format (no complaint), how do I ensure all the branches in one project - most likely of an older format - stay in that format as I create new branches and do merges and stuff? | 01:59 |
| PureRumble | Now what do you propose I do on laptop to continue working? | 02:00 |
| RAOF | PureRumble: So, the next thing I'd do is push that branch up to launchpad, so it's easily available everywhere :). If that's not what you want to do, then you can “bzr branch sftp://the-main-computer/path/to/that/branch” on the laptop. | 02:01 |
| cody-somerville | jacseen, create a repository to place all your branches in | 02:01 |
| PureRumble | but if I'm not misstaken then when you create a new branch it will go its own way... unless you merge them, right? | 02:02 |
| RAOF | PureRumble: Right. | 02:02 |
| jacseen | cody-somerville, I never actually created a repo for my branches, the tutes didn't explain them. Do these repos force all branches inside them to remain the same format, or just affects the format of newly created branches(the main requirement)? | 02:03 |
| RAOF | So, once you're done working on your laptop, you can either (a) “bzr push sftp://the-same-thing” to push your changes to the main computer or (b) Merge on the main computer from the laptop | 02:03 |
| PureRumble | But there would still be inconvenience if I'm working with php code, right? Because webserver is on main computer. I would have to pull/push on laptop and then connect to computer through http to verify each little change I wanna see, right? | 02:05 |
| RAOF | Unless you run a webserver on your laptop, right. | 02:09 |
| PureRumble | Yes but then it becomes a matter of keeping webserver configuration up-to-date too :). RAOF, lifeless, spiv thx for your help. I think I have enough to walk on from here. | 02:15 |
| jacseen | Is there anyway to 'downgrade' a branch from a newer version to like 'pack-0.92' to maintain compatibilty across a whole project? Or must a person copy over the data files between the branches? | 02:21 |
| spiv | jacseen: you can use 'bzr upgrade' to downgrade too | 02:22 |
| spiv | jacseen: but not all downgrades are possibly, e.g. you can't go from 2a to pack-0.92 because 2a stores some data that pack-0.92 cannot represent | 02:23 |
| jacseen | spiv by passing the format in cmdline. OK thanks | 02:23 |
| jacseen | spiv that's what I was trying to confirm. Makes sense. | 02:24 |
| jacseen | what is launchpad 'branch format 7' really in bzr terms? | 02:25 |
| spiv | jacseen: the branch format used by the "1.6" format option and newer, but branch formats aren't much of a compatibility issue. | 02:28 |
| spiv | jacseen: it's the repository format that is usually the problem | 02:28 |
| spiv | jacseen: it might be a bit confusing because the command-line options actually refer to combinations of working-tree/branch/repository formats, but I think Launchpad just shows the individual branch and repository formats. | 02:29 |
| jacseen | spiv and here I thought I had it almost figured out :P | 02:30 |
| * igc heads off for a few days of holidays | 02:48 | |
| jacseen | thank you all for the added information, eventually I'll know everything again. :p | 02:50 |
| mac9416 | jacseen, then will come another big upgrade. :-) | 02:51 |
| mwhudson | here's a quiz | 03:38 |
| NfNitLoop | 42 | 03:38 |
| mwhudson | what's going on here: http://pastebin.ubuntu.com/355857/ | 03:40 |
| thumper | poolie: ping | 03:44 |
| poolie | pong | 03:45 |
| thumper | poolie: I have a bug | 03:45 |
| thumper | poolie: see mwhudson's paste | 03:45 |
| thumper | poolie: I'm trying to work out a summary | 03:45 |
| thumper | poolie: the actual branches in the pastebin have moved | 03:45 |
| thumper | poolie: but I have kept the branch for bug triage | 03:45 |
| thumper | poolie: it is now lp:~launchpad-pqm/bzr-hg/broken | 03:45 |
| poolie | if in doubt, file a bug with the exception and the innermost function name | 03:46 |
| poolie | from -Derror | 03:46 |
| thumper | ok | 03:46 |
| poolie | with that stuff in the subject line, i mean | 03:46 |
| poolie | and the tracebac in the description | 03:46 |
| thumper | poolie: https://bugs.edge.launchpad.net/bzr/+bug/506777 | 03:48 |
| ubottu | Launchpad bug 506777 in bzr "InvalidRevisionSpec: Requested revision: u'281' does not exist in branch" [Undecided,New] | 03:48 |
| poolie | ok | 03:54 |
| poolie | thumper: is this urgent? | 03:58 |
| thumper | poolie: no, I've worked around by making an unstacked branch | 03:58 |
| poolie | high?medium? | 03:58 |
| thumper | on the whole, it seems a little broken, so high | 04:04 |
| thumper | but I also have that feeling about committing to a stacked branch | 04:04 |
| lifeless | what, that you can't ? :) | 04:06 |
| poolie | thumper: just in case jelmer did something weird in the history it might be useful to check that branch before pushing | 04:10 |
| thumper | poolie: it works for an unstacked branch | 04:10 |
| poolie | i'll have a bit of a poke at it | 04:10 |
| thumper | lifeless: EPARSE | 04:10 |
| lifeless | thumper: commit to a stacked branch. | 04:12 |
| thumper | lifeless: as far as we are aware, if you have a stacked branch, you can't commit to it (except using a heavy weight checkout) | 04:13 |
| lifeless | thats right | 04:13 |
| thumper | we want to commit directly to the branch | 04:14 |
| thumper | we now have at least two different use cases in LP for this | 04:14 |
| lifeless | cool | 04:16 |
| lifeless | would love to see that fixed ;) | 04:16 |
| thumper | poolie: how do I go about increasing the priority of that? | 04:26 |
| poolie | which one? commit to a branch or log? | 04:27 |
| spiv | commit to a stacked branch (bug 375013) is already marked High, FWIW. | 04:28 |
| ubottu | Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013 | 04:28 |
| === Sam__ is now known as SamB_XP | ||
| jacseen | what does it mean when bzr claims a branch is 'format: unnamed'? lp:~keryx-admins/keryx/devel/ | 04:48 |
| jacseen | from 'bzr info'. | 04:49 |
| jacseen | what format should I use for a repo/branch in order to make it the same format to ease the merges? | 04:50 |
| spiv | jacseen: try 'bzr info -v' | 04:54 |
| spiv | jacseen: it just means that the combination of tree/branch/repo format doesn't match one you can name via the usual options (like --pack-0.92) | 04:54 |
| spiv | jacseen: in this case, | 04:55 |
| spiv | jacseen: --2a (i.e. the default format that bzr 2.0 creates) is fine | 04:55 |
| jacseen | still 'format: unnamed' | 04:55 |
| jacseen | alright | 04:56 |
| spiv | jacseen: oh, in fact that is regular combination, and just affected by a bug to do with 'bzr info' over the smart server protocol | 04:56 |
| spiv | jacseen: -v shows extra lines like "repository: Remote: Repository format 2a ..." for me, but maybe that's not in 2.0 (I'm using lp:bzr) | 04:56 |
| jacseen | Oookaaay, I won't try to understand taht one yet | 04:56 |
| spiv | jacseen: as a workaround, you can use 'bzr info nosmart+lp:~keryx-admins/keryx/devel/' :/ | 04:57 |
| spiv | jacseen: sorry about that bug | 04:57 |
| jacseen | Format: | 04:57 |
| jacseen | control: bzr remote bzrdir | 04:57 |
| jacseen | branch: Remote BZR Branch | 04:57 |
| jacseen | repository: bzr remote repository | 04:57 |
| spiv | Yeah, the 2.1 betas do a little better there. | 04:58 |
| jacseen | my main concern is, will my branches in 2a format cause extra headaches when merging back into the branches upstream? | 04:58 |
| spiv | jacseen: no, 2a is exactly the right format | 04:58 |
| spiv | jacseen: that branch is in fact in 2a format | 04:58 |
| spiv | jacseen: there's just a bug with bzr info that stops that from being obvious :( | 04:59 |
| SamB_XP | jacseen: upstream of what ? | 04:59 |
| spiv | jacseen: just to be clear, "upstream" here == lp:~keryx-admins/keryx/devel/, yes? | 04:59 |
| jacseen | is that why my bzr 1.16 complained bitterly about rich-root when I tryed merging pack-0.92 into that one? | 04:59 |
| jacseen | spiv yes on the upstream currently | 05:00 |
| spiv | jacseen: yes, you can upgrade (and pull, merge, etc) from pack-0.92 into 2a, but not vice versa, because of rich roots. | 05:01 |
| jacseen | hmm interesting, I thought I was going that direction | 05:01 |
| spiv | jacseen: 2a is a much better format than pack-0.92 (not just because of rich roots), and it's the default in 2.0, so I definitely recommend using it unless you have a good reason not to. | 05:01 |
| jacseen | on Keryx Project, lp:keryx, we were mainly using pack-0.92, but now with the admins changing/renaming the primary branches into stable/unstable, those are no longer in pack-0.92 it seems and is cuding slight conflicts when I try to branch them to have a local copy | 05:04 |
| jacseen | but I upgraded to bzr 2.0.3, so now my branches are all 2a, so that should help my side | 05:05 |
| spiv | Yes, sounds like it should :) | 05:05 |
| spiv | Things should be faster now, too :) | 05:05 |
| jacseen | spiv: great so now I have to finish rebranching all keryx branches and translate my code changes over. No problem. Solution found | 05:07 |
| jacseen | spiv: thanks | 05:07 |
| spiv | jacseen: you're welcome, glad I could help. | 05:07 |
| poolie | hi spiv, all | 05:26 |
| === EdWyse_Mobile1 is now known as EdWyse_Mobile | ||
| vila | hi all | 07:04 |
| spiv | Hmm, I think I'm close to having a working NEWS file merge plugin. | 07:06 |
| bialix | heya bzr | 07:23 |
| spiv | Woo, it works. | 07:24 |
| spiv | So, that's a useful proof-of-concept for the per-file merge hook. | 07:25 |
| spiv | Also shows where things are a bit more cumbersome than necessary. | 07:25 |
| * spiv submits | 07:25 | |
| spiv | Ok, merge proposal submitted. I'm done for the day. | 07:41 |
| poolie | cheerio spiv | 07:44 |
| poolie | hope we see you tomorrow :) | 07:44 |
| poolie | hi vila | 07:44 |
| spiv | poolie: who knows! :) | 07:44 |
| vila | hey poolie ! Thanks for your feedbackS on conflicts, replying now | 07:50 |
| poolie | thanks | 07:50 |
| poolie | i hope that didn't sound too critical | 07:50 |
| vila | nope, never :) | 07:51 |
| vila | The problem domain is complex anyway, so it's hard to find the small steps :) | 07:56 |
| poolie | well, goodnight | 07:59 |
| quicksilver | vila: good morning | 08:16 |
| vila | good morning quicksilver | 08:16 |
| vila | I think I read you had a solution but not what that solution was :) | 08:17 |
| quicksilver | vila: I believe I have an approach which solves my problem. | 08:17 |
| vila | quicksilver: and the approach is ? | 08:28 |
| quicksilver | vila: after the manually fixed poison revision, proceed up the history tree of the old (poisoned) branch | 08:32 |
| quicksilver | vila: for each revision which is merely a plain commit, use bzr replay to replay it. | 08:32 |
| quicksilver | for each merge do the following: | 08:32 |
| quicksilver | 1. bzr merge -r"revid:exact-revid-of-merge-source" | 08:32 |
| quicksilver | 2. bzr revert . # discard those changes but keep them registered | 08:32 |
| quicksilver | 3. bzr diff -rA.B.C..D.E.F > my.diff # get a copy of the diff which this merge should result in | 08:33 |
| quicksilver | 3. patch -p0 < my.diff # apply most of it | 08:33 |
| quicksilver | 5. for i in `egrep '^=== added' my.diff | awk -F"'" '{print $2}'`; do bzr add $i; done; # record the added files as added | 08:35 |
| vila | That should work except for the renames | 08:36 |
| quicksilver | 6. manually process any binary files added or changed using bzr cat (binary files don't get included in the diff) | 08:36 |
| vila | and the binary files, yes, 'bzr shelve' should help if called at the right time | 08:37 |
| bialix | spiv: cool! (re per-file merge) | 08:38 |
| quicksilver | 7. egrep '^=== renamed' to identify any renames and process them by hand | 08:38 |
| bialix | hi spiv, vila | 08:38 |
| vila | hi bialix | 08:38 |
| quicksilver | vila: I thought about bzr shelve but couldn't work out how to use it for this. | 08:41 |
| quicksilver | vila: of course br bundle format would be ideal, but there is no way to say "act on the add/rename/modify directives in this bundle whilst ignoring the revids" | 08:42 |
| vila | the poisoned revisions appears in the history of the branches you are merging from right > | 08:45 |
| vila | s/>/?/ | 08:45 |
| quicksilver | vila: no, they don't | 08:47 |
| vila | I don't understand why you do 2. bzr revert then | 08:47 |
| quicksilver | vila: because the merge causes large, complex conflicts. | 08:53 |
| quicksilver | vila: and the original developer resolved them | 08:53 |
| vila | ha, yes, of course | 08:55 |
| quicksilver | and I want to use his resolution, which lies in that diff. | 08:55 |
| quicksilver | gah. Now I have a conflict in a plain replay. This means I made a mistake, I think | 08:55 |
| quicksilver | oh well, it's getting more and more automated. I think I'll start again it will be faster now. | 09:00 |
| vila | quicksilver: you should mail the list or file a bug against bzr-rewrite, we definitely needs that feature | 09:01 |
| quicksilver | vila: maxb thought it might be possible with his branch of rewrite but I couldn't make it work. | 09:02 |
| quicksilver | vila: this could easily be my fault :) | 09:02 |
| vila | quicksilver: *how* you end up make it work is the interesting part :) | 09:03 |
| vila | I'm sure maxb will be interested too :) | 09:03 |
| * bialix hates such lame posts: http://community.livejournal.com/shlomif_tech/41922.html grr | 09:06 | |
| quicksilver | vila: I will mail the list once I've got it all sorted. This is something of a crisis right now though. | 09:12 |
| vila | quicksilver: Sure, I understand that | 09:13 |
| === timchen1` is now known as nasloc__ | ||
| asabil | quicksilver, I think bzr-rewrite doesn't support what you need yet | 09:40 |
| asabil | I started working on a bzr filter-branch command for bzr-rewrite a while ago, it only supported rewriting the commit messages and it never got merged | 09:40 |
| asabil | you can also use bzr fast-export/fast-import | 09:41 |
| asabil | they have the ability to filter out files | 09:41 |
| quicksilver | vila: hmm. No. I think my method is unsound after all. | 10:18 |
| vila | :-/ | 10:19 |
| quicksilver | vila: when I do "bzr revert ." after the merge that reverts the added files | 10:19 |
| quicksilver | then when I readd them manually | 10:19 |
| quicksilver | they are flagged as coming in in *that* revision | 10:19 |
| quicksilver | rather than coming in in the revision they came in | 10:19 |
| quicksilver | which means they conflict on the next merge. | 10:19 |
| quicksilver | because bzr thinks they're different files. | 10:19 |
| quicksilver | I think really I want to only revert the conflicted files. | 10:20 |
| quicksilver | or, just bzr cat the conflicted files from the right revision. | 10:20 |
| vila | hmm, yes, you should preserve the file-ids | 10:20 |
| quicksilver | is there a way to instruct a merge always to give priority to OTHER? | 10:21 |
| vila | if you have only text conflicts then bzr cat -rnnn FILE ; bzr resolve FILE, should to it | 10:21 |
| quicksilver | bzr cat -rnnn FILE > FILE, you mean | 10:22 |
| quicksilver | but yes | 10:22 |
| vila | quicksilver: There is a merge proposal about that for tree shape conflicts: https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785 | 10:22 |
| vila | but that doesn't address text conflicts where more cases are needed | 10:25 |
| * quicksilver nods | 10:28 | |
| lifeless | quicksilver: you shouldn't generally do 'revert .' - because that *keeps* the record of the merge | 10:29 |
| quicksilver | lifeless: but that's exactly why I'm doing it | 10:31 |
| quicksilver | lifeless: I need to keep the record of the merge | 10:31 |
| quicksilver | but I don't want to do the hard work to resolve the conflicts again | 10:31 |
| quicksilver | so I want ot manuallly re-apply the previous conflict resolution. | 10:31 |
| * rml waves at quicksilver | 10:31 | |
| quicksilver | vila: for i in `bzr conflicts | egrep '^Text conflict in' | awk '{print $4}'`; do echo $i; bzr cat -r"revid:$MERGEID" $i > $i; bzr resolved $i; done; | 10:35 |
| vila | bzr pull --overwrite -r$MERGED ; bzr uncommit ; bzr shelve --all -m $MERGED | 10:38 |
| vila | I think you can prepare the changes with that and then apply them after bzr revert . | 10:39 |
| vila | bzr resolve --auto should then get rid of the text conflicts | 10:40 |
| quicksilver | vila: I have a different approach, which is maybe equivalent. | 10:40 |
| quicksilver | vila: suppose X.Y.Z is the revision which merges $MERGEID (and possibly fixes some conflicts or adds some more code) | 10:41 |
| quicksilver | vila: first bzr merge -R"revid:$MERGEID" | 10:41 |
| quicksilver | vila: then resolve all conflicts in favour of $MERGEID | 10:41 |
| quicksilver | vila: now, bzr merge -rX.Y.Z | 10:41 |
| quicksilver | vila: and that applies the new changes but it "notices" the $MERGEID is already merged and so that's OK. | 10:41 |
| quicksilver | vila: seemed to work just now. | 10:41 |
| vila | cool, you'll get X.Y.Z as an additional parent though | 10:42 |
| vila | but that may be better to show where you add to tweak your history | 10:42 |
| quicksilver | yeah, I don't really care about the extra parent | 10:43 |
| vila | quicksilver: on the other hand if your merged branches are not poisoned why not just merged them as a whole ? | 10:43 |
| quicksilver | the general soundness is more important ) | 10:43 |
| quicksilver | vila: because of the conflicts? | 10:44 |
| vila | ha, hmmm, yeah, hard to tell from here if resolving them once is enough or if each branch brings its own set, so yeah 'bzr resolve --take-theirs' ftw | 10:45 |
| vila | this is a case where you *knwo* you want the conflicts resolved in your wt as they were resolved in the merged branch, without thinking about it | 10:46 |
| vila | s/knwo/know/ | 10:46 |
| quicksilver | ah bother, it didn't work with file add/rename conflicts | 10:47 |
| * quicksilver backtracks and thinks again | 10:47 | |
| vila | quicksilver: https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785 *implement* --take-theirs for add/rename conflicts ! | 10:55 |
| quicksilver | yes, I saw it. | 10:58 |
| quicksilver | "bzr merge -rX.Y.Z" is a bad idea. | 10:58 |
| quicksilver | it brings the poison back in. | 10:59 |
| vila | ha, so the poison is in the other branches too then | 10:59 |
| quicksilver | no, X.Y.Z isn't the "other" branch | 11:02 |
| quicksilver | X.Y.Z was the bad branch anyway | 11:02 |
| vila | how about 'merge -cX.Y.Z' then ? | 11:03 |
| quicksilver | oh, I didn't know about that one | 11:06 |
| quicksilver | what does -c do? the help page isn't very detailed :) | 11:07 |
| vila | I'm unsure about it in your particular case :) It's supposed to bring only the changes in the specified revision | 11:08 |
| quicksilver | vila: bzr merge -cX.Y.Z gives bzr: ERROR: exceptions.AssertionError: Unknown kind 'relocated' | 11:12 |
| * vila bangs head on desktop | 11:12 | |
| vila | 2.0.1 right ? | 11:14 |
| quicksilver | 2.0.3 actually | 11:14 |
| quicksilver | upgraded yesterday whilst tearing hair out | 11:14 |
| vila | ha, gee, I thought I went in the twilight zone for a second, I was sure we had the reverse conversation yesterday :-D 2.0.3 ? 2.0.1 actually | 11:15 |
| vila | I'm 60% sure some bugs has been fixed in at least bzr.dev and may be bzr-2.1betaxx | 11:16 |
| vila | but anyway, did you try the pull/uncommit/shelve trick ? | 11:17 |
| vila | It's supposed to record the actual changes for each revision so you'll get a poor-man replay, you can still insert some merge/revert . to set the parents | 11:18 |
| quicksilver | vila: No. I think I'll try that next. | 11:21 |
| vila | quicksilver: remember that shelve is tight to the wt so be ready for some pull --overwrite to set the right wt or to copy/move the .bzr/checkout/shelf directory in the right place | 11:24 |
| quicksilver | vila: "wt" ? | 11:24 |
| vila | working tree | 11:24 |
| * quicksilver nods | 11:25 | |
| quicksilver | but pull --overwrite complete nukes my branch history? | 11:26 |
| vila | nukes is a bit strong :) It makes your branch history the same as the one you're pulling from | 11:29 |
| vila | and also updates the wt | 11:29 |
| quicksilver | vila: but I don't want to lose the branch history, do I? | 11:33 |
| quicksilver | or are you suggesting a use an auxiliary working tree and merge between | 11:34 |
| vila | yup, when in doubt, always use a scratch monkey | 11:34 |
| quicksilver | vila: in particular, a bzr pull --overwrite will pull the poison back in. | 11:34 |
| vila | yes, but it shouldn't pollute the shelved changes | 11:34 |
| vila | when all your changes are ready, you can then, bzr pull --overwrite -r<clean_revno> ../<dirty branch> and start from there | 11:35 |
| vila | pull --overwrite -rrevno, gives you a branch and a working tree exactly as they were after the commit that created revno | 11:37 |
| quicksilver | something in the help page for shelve implies that it only applies to text changes though | 11:37 |
| quicksilver | so it won't fix my rename / binary problems? | 11:37 |
| vila | if you uncommit/shelve, you should get unpoisoned changes from that | 11:38 |
| vila | file a bug about that, shelve in bzr -core was rewritten from scratch to address shel from bzrtools relying on patch | 11:39 |
| vila | if you get the wrong impression there, the doc should be fixed | 11:39 |
| quicksilver | Right. | 11:40 |
| quicksilver | So, I need one shelf per merge? | 11:40 |
| quicksilver | uncommit each merge point to a shelf | 11:40 |
| quicksilver | then pull a clean revision | 11:41 |
| quicksilver | and unshelve one merge at a time | 11:41 |
| quicksilver | well, (bzr merge ...; bzr revert.) to set the parent | 11:41 |
| quicksilver | and then unshelve the shelved version of the merge changeset on top | 11:41 |
| vila | that's the idea | 11:42 |
| quicksilver | do shelves show up as a single change | 11:42 |
| quicksilver | or do they look like a merge? | 11:42 |
| vila | think of shelves as you think about patches | 11:43 |
| vila | you add or subtract them from a working tree, no merges or commits are involved | 11:44 |
| quicksilver | so I still want to replay the non-contentious revisions | 11:44 |
| quicksilver | if I want to keep as much of the history as possible | 11:44 |
| vila | be careful to not bring back poisoned revisions though, even if the poisoned file is not in your mainline revisions setting a poisoned revision as a parent will still reference it in the repository | 11:45 |
| vila | so while you can get back the changes from the poisoned branches, you can't get their full history | 11:46 |
| quicksilver | yup | 11:48 |
| quicksilver | well replay makes new revisions, it doesn't reference poisoned ones | 11:48 |
| quicksilver | I guess replay is a bit like the uncommit/shelve/commit trick for a single revision. | 11:49 |
| vila | yup, simpler, otherwise you have to come up with some mapping for the merged revisions | 11:50 |
| quicksilver | vila: right. So basically your point is that shelves > diffs, because shelves can include renames and binary files etc. | 11:53 |
| quicksilver | vila: that makes sense but I kind of coped with renames and binary files anyway although it was a little painful. | 11:53 |
| quicksilver | vila: however it *doesn't* solve the file-id problem for added files. | 11:53 |
| quicksilver | (bzr merge -r$MERGEID; bzr revert .) is broken because it loses the file-ids for files added in that merge. | 11:53 |
| quicksilver | similarly, if you shelve an uncomitted merge, you lose the file-ids, surely? | 11:55 |
| vila | no, shelve should preserve the file-ids | 12:00 |
| quicksilver | ah, OK | 12:00 |
| quicksilver | in that case perhaps I can see how to make this work | 12:01 |
| quicksilver | using two branches | 12:01 |
| quicksilver | I mean, two working trees | 12:01 |
| quicksilver | one working tree stays clean and I replay along it for the simple revisions. | 12:01 |
| quicksilver | when I get to a merge, I use a dirty working tree to pull to the merge, uncommit it, shelve it | 12:01 |
| quicksilver | then pull --overwrite to get the *clean* tree in | 12:02 |
| quicksilver | and unshelve that merge | 12:02 |
| quicksilver | vila: is that what you suggest? | 12:02 |
| vila | err, no, I suggest preparing all the shelves first in wt-dirty, then move them to wt-clean and apply them there when needed | 12:04 |
| vila | but you get the general idea yes | 12:04 |
| vila | quicksilver: lunch time here, I'll be back in ~1 hour, anything urgent before ? | 12:05 |
| maxb | Under what circumstances does bzr-svn need to build a fileidmap-v3.knit ? | 12:05 |
| quicksilver | vila: no, thanks for all your help | 12:05 |
| vila | quicksilver: youre' welcome, keep giving feedback | 12:06 |
| quicksilver | vila: of course, each time I branch/pull a bad revision it takes ages and uses up all my machine's memory, but that's life I suppose | 12:23 |
| quicksilver | vila: when trying to shelve a complex merge : bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-150')] | 12:34 |
| quicksilver | vila: even if I commit and uncommit it's no better | 12:38 |
| quicksilver | apparently some kinds of change can't be shelved... | 12:38 |
| === mrevell is now known as mrevell-lunch | ||
| quicksilver | and to whoever it was who was suggesting fast-export | 12:48 |
| quicksilver | I read that fast-export / import roundtrip discards file-ids | 12:48 |
| quicksilver | so that's not the answer | 12:48 |
| quicksilver | although I read some bug reports to suggest it *does* have file-ids | 12:50 |
| quicksilver | hmm | 12:50 |
| quicksilver | well, I'll try it. | 13:00 |
| vila | quicksilver: you got malformed transform while shelving a wt without conflicts ? | 13:03 |
| quicksilver | vila: yes. | 13:05 |
| vila | quicksilver: internally shelve is supposed to serialize an intermediate representation that supports everything bzr support (bar conflicts and pending merges I think) | 13:05 |
| quicksilver | ah well there was a pending merge. | 13:05 |
| quicksilver | but that's the point of what I'm doing isn't it | 13:06 |
| vila | hmm, no, you want only the changes themselves, not the parents or at least not the poisoned ones and you're supposed to fake the others anyway | 13:07 |
| quicksilver | well, this wasn't a poisoned one. | 13:07 |
| quicksilver | but how do I get the changes from a merge without the pending merge? | 13:07 |
| quicksilver | you said to go to the next revision, uncommit, and shelve :) | 13:07 |
| quicksilver | if I do that, I have a pending merge | 13:07 |
| vila | pull --overwritw/uncommit/shelve | 13:07 |
| quicksilver | yes, but if the thing I uncommit is a merge | 13:07 |
| vila | oh, wait | 13:07 |
| quicksilver | then I have a pending merge after the uncommit | 13:08 |
| quicksilver | naturally. | 13:08 |
| quicksilver | incidentally, bzr fast-export eventually runs out of memory and dies. | 13:08 |
| vila | pull --overwritw/uncommit/bzr revert --forget-merges/shelve | 13:08 |
| vila | sorry about that, silly me :-/ | 13:08 |
| quicksilver | ah | 13:09 |
| quicksilver | I also had a problem where pull --overwrite pivoted the tree | 13:09 |
| quicksilver | so that uncommit did the wrong thing | 13:09 |
| quicksilver | so I had to re-merge to get the right "mainline" | 13:09 |
| vila | pull --overwrite always does that, it really puts you into the state when the revision was committed | 13:10 |
| quicksilver | I know | 13:10 |
| quicksilver | I understand why, I was just remarking | 13:10 |
| quicksilver | because the tree I'm recovering is a far-right branch | 13:10 |
| vila | I find qlog really helpful for that | 13:10 |
| quicksilver | occasionally I need to pivot the line | 13:10 |
| quicksilver | but that's OK, I'm used to this. | 13:11 |
| quicksilver | I'm still getting bzr: ERROR: Tree transform is malformed | 13:11 |
| quicksilver | even after a --forget-merges | 13:11 |
| vila | oh, ok, hard to visualize from here :-// | 13:11 |
| quicksilver | so I have a bunch of uncommitted changes in my 'dirty' wt | 13:11 |
| quicksilver | they are essentially the changes corresponding to a merge | 13:12 |
| quicksilver | but they have forgotten about the merge | 13:12 |
| quicksilver | because I did --forget-merges. | 13:12 |
| quicksilver | and I still can't shelve them :( | 13:12 |
| vila | that's weird, shelve and commit are supposed to use the same code... can you commit ? | 13:12 |
| quicksilver | Yes, I can | 13:13 |
| quicksilver | I tried commit/uncommit at one point | 13:13 |
| quicksilver | just to make sure nothing odd was doing on | 13:13 |
| * quicksilver does it again | 13:13 | |
| * vila bangs head on desktop again | 13:13 | |
| quicksilver | Yup. | 13:13 |
| quicksilver | I can definitely commit fine. | 13:13 |
| quicksilver | and after I comment "bzr st" says the tree is clean | 13:14 |
| quicksilver | (that is, it says nothing) | 13:14 |
| quicksilver | and I can uncommit again, and shelve crashes again :) | 13:14 |
| vila | uncommit/shelve from there ? | 13:14 |
| quicksilver | yes, I just did. It crashes. | 13:14 |
| vila | anything suspicious in bzr st ? | 13:15 |
| quicksilver | 10 files removed, 40 added, 1 renamed, 80 modified | 13:15 |
| quicksilver | nothing out of the ordinary though | 13:15 |
| quicksilver | although it certainly is a big merge | 13:16 |
| vila | haystack... | 13:16 |
| maxb | I think the best way to do this would be to fast-export | fast-import *JUST* the changes after the poison revision | 13:17 |
| quicksilver | maxb: fast-export crashes on all poisoned revisions. | 13:17 |
| quicksilver | maxb: the poison is too much for fast-export to take. | 13:17 |
| maxb | ugh | 13:17 |
| maxb | How many poisoned revisions are there, about? | 13:17 |
| vila | quicksilver: you've got quite an assassin in your team... | 13:18 |
| quicksilver | Python(43161) malloc: *** mmap(size=691982336) failed (error code=12) | 13:18 |
| quicksilver | *** error: can't allocate region | 13:18 |
| quicksilver | *** set a breakpoint in malloc_error_break to debug | 13:18 |
| quicksilver | bzr: out of memory | 13:18 |
| quicksilver | maxb: just one. | 13:18 |
| maxb | And are there valuable changes in the same revision as the poison? | 13:18 |
| quicksilver | yes | 13:18 |
| maxb | :-/ | 13:18 |
| quicksilver | but I reconstructed that one revision by hand easily enough | 13:18 |
| quicksilver | bzr uncommit; bzr rm big-file; bzr commit -m"<copy-paste-long-commit-message>" | 13:18 |
| quicksilver | that was the easy bit. | 13:18 |
| quicksilver | the hard bit is replaying the future. | 13:19 |
| maxb | Right, well what I would do is to branch just before the poison. Manually reconstruct and recommit that one rev. And fast-export / fast-import the subsequent revisions | 13:19 |
| quicksilver | you can fast-export just a revision range? | 13:19 |
| quicksilver | I didn't know that. | 13:19 |
| vila | argh, I thought that was the failing run ! | 13:19 |
| maxb | In order to make fast-import append to an existing history, it's likely going to be necessary to use --export-marks and --import-marks with manual editing of the revid in the marks file | 13:20 |
| maxb | Also you're likely going to have to fix up the marks file because of a bzr-fastimport bug, where fast-import and fast-export use slightly different syntax in their marks! | 13:20 |
| quicksilver | vila: ? | 13:21 |
| vila | I thought you tried fast-export with a range and it crashed, it's worth a try I think (but no first hand experience with it here) | 13:22 |
| quicksilver | maxb: well, fast-export with a range is certainly very fast. | 13:23 |
| vila | maxb: the file-ids will be preserved right ? | 13:23 |
| maxb | I'm hoping they will for existing files | 13:23 |
| maxb | Which should be good enough | 13:23 |
| maxb | I admit to not really being sure | 13:23 |
| quicksilver | I don't see any file-ids in the .fi file | 13:24 |
| maxb | Correct | 13:24 |
| quicksilver | maybe I'm looking in the wrong bit | 13:24 |
| maxb | I'm hoping that it will necessarily have to match onto the existing files by path | 13:24 |
| quicksilver | well some of the conflict resolution at merges is where files collide | 13:24 |
| quicksilver | so the resolution to the conflict is to rename one | 13:24 |
| quicksilver | so it's pretty import to preserve that part of conflict resolution. | 13:25 |
| maxb | Ah. I have no idea how well that will work, then | 13:25 |
| maxb | I don't know enough about the guts of fastimport to understand what it will do here | 13:26 |
| quicksilver | well no harm trying it | 13:27 |
| vila | quicksilver: everybody involved in on OSX ? (Trying to rule out some path encoding problems) | 13:27 |
| quicksilver | I have the fast export file. | 13:27 |
| quicksilver | vila: no, mixture of OSX/linux | 13:27 |
| quicksilver | vila: although the author of the problem branch is on OSX and so am I | 13:27 |
| maxb | quicksilver: Did you --export-marks=somefilename? | 13:27 |
| quicksilver | maxb: yes. | 13:27 |
| quicksilver | maxb: just making a branch of the "manually fixed-up" revision to try to import into. | 13:27 |
| maxb | quicksilver: I think that two manual edits to the marks file will be needed | 13:28 |
| maxb | First, check whether all the data lines (line 3 and onwards I think) start with a colon. If they don't, it's a bug, and you'll need to edit to fix that | 13:29 |
| quicksilver | no, they all start just with a number | 13:29 |
| quicksilver | add colons to all? | 13:29 |
| maxb | Yes | 13:29 |
| quicksilver | done | 13:30 |
| maxb | Second, if you look at the first commit in the .fi file, and see what its "from :XXX" line says - and then change the corresponding mark's revid to be the revid of your un-poisoned revision that you want to play history on top of | 13:30 |
| quicksilver | (hurrah for C-x r t) | 13:30 |
| vila | quicksilver: hehe | 13:30 |
| maxb | (also hurrah for vim visual block mode :-) ) | 13:30 |
| quicksilver | there isn't a from | 13:30 |
| vila | C-x r : useless until you need it and soooo nice then | 13:31 |
| quicksilver | the second commit is "mark :2" and "from :1" but the first commit has no from line. | 13:32 |
| maxb | quicksilver: umm?! No from, no merge :XXX either? | 13:33 |
| quicksilver | nope | 13:33 |
| quicksilver | commit, mark, committer, data, (the commit message) and then the actual changes start | 13:33 |
| maxb | Oh, on an unrelated note, you probably want to export with --no-plain | 13:35 |
| maxb | OK, change of idea re the marks | 13:38 |
| maxb | *Add* a line reading "from :1000000" to the initial revision | 13:38 |
| maxb | *Delete* all the data lines from the marks file, and replace them with one saying :1000000 revid-of-revision-that-should-be-new-parent | 13:39 |
| === mrevell-lunch is now known as mrevell | ||
| quicksilver | hmm ok | 13:40 |
| quicksilver | 13:40:25 Starting import of 50 commits ... | 13:40 |
| quicksilver | ABORT: exception occurred processing commit :1 | 13:40 |
| quicksilver | bzr: ERROR: exceptions.KeyError: ':1' | 13:40 |
| * rubbs is confused... is repository surgery being performed? | 13:41 | |
| quicksilver | rubbs: sadly not. | 13:42 |
| quicksilver | rubbs: would like to, though. | 13:42 |
| vila | rubbs: kind of, lossy rebuild instead | 13:42 |
| quicksilver | vila: the reason I did a full fast-export the first time around, by the way, is that I read this is actually a documented purpose of fast-export ;) -x to exclude a CD image added in error. | 13:43 |
| quicksilver | vila: not much use if it gives out of memory when processing the file though. | 13:43 |
| quicksilver | and I have a suspicion it will kill all the file-ids making it unmergeable. | 13:43 |
| vila | bug filing time again :-/ | 13:43 |
| * quicksilver doesn't even know which parts of what's going on are bugs. | 13:44 | |
| quicksilver | presumably the uncommit which I can't shelve is a bug. | 13:45 |
| quicksilver | I think I'm going to have to revert to slow replay approach. | 13:45 |
| rubbs | ah... gotcha... I'll just sit back and watch. This is fasinating(sp?) | 13:46 |
| vila | that's one yes, abentley may have an explanation about what kind of change can be committed but not shelved | 13:46 |
| vila | fast-export blowing out memory may be one too (but it may be a dupe of the one you get with bzr itself) | 13:46 |
| quicksilver | yes | 13:47 |
| maxb | quicksilver: What's the first occurrence of :1 in your fi file? | 13:47 |
| quicksilver | and some operations don't crash | 13:47 |
| quicksilver | (which is just as well, because otherwise this branch would be totaly useless) | 13:47 |
| quicksilver | some operations give the memory error but still succeed | 13:47 |
| quicksilver | which I find fairly mysterious. | 13:47 |
| quicksilver | maxb: mark :1 near the top | 13:48 |
| maxb | huh | 13:48 |
| quicksilver | maxb: line 5, after 3 "feature" lines, and one "commit" line | 13:48 |
| vila | quicksilver: As said yesterday, 2.1 fixed several memory issues, that could help | 13:48 |
| maxb | quicksilver: pastebin the stacktrace? | 13:48 |
| vila | quicksilver: quick check, you still use *only* 0.92 branches right ? | 13:49 |
| quicksilver | maxb: http://pastebin.com/d6f95e4cf | 13:49 |
| quicksilver | vila: these fastimport tests are in a 2a branch | 13:50 |
| quicksilver | vila: in fact, probably all the fixup work has been in a 2a branch | 13:50 |
| quicksilver | one of the first things I did was upgrade the branch | 13:50 |
| quicksilver | because, initially, I thought that might solve the problem. | 13:50 |
| vila | ok | 13:50 |
| * vila strike yet another cause | 13:51 | |
| * maxb confused, sorry | 13:52 | |
| maxb | afk for a bit | 13:52 |
| quicksilver | if 2.1 fixes bzr-fastexport so that it works even on the huge file, then one solution would be to bzr-fastexport *all* my branches, including the non-poisoned one | 13:52 |
| quicksilver | and then reimport them all, thus retaining their relationships | 13:53 |
| quicksilver | (using -x to remove the bad file at export time) | 13:53 |
| quicksilver | but that's a big if. | 13:53 |
| vila | yeah :-/ | 13:55 |
| quicksilver | vila: OK, in the absence of other smart ideas, I'm going to return to "replay, remerge, and carefully re-resolve conflicts" | 14:02 |
| quicksilver | I may even use rsync. | 14:03 |
| vila | without looking at your data, it's hard to understand what makes shelve crash :-/ rsync/bzr st/bzr diff should help you validate your changes... | 14:04 |
| quicksilver | vila: I'm inclined to guess that fixing shelve is not the shortest path to my solution ;) | 14:05 |
| vila | fixing it now, working around the problem, may be... | 14:05 |
| vila | s/now/no/ | 14:05 |
| vila | or... bzr pull -overwrite -r<some revno> in wt-dirty ; cd wt-clean; bzr merge ../wt-dirty ; bzr revert --forget-merges ? | 14:08 |
| vila | hmm, will not allow you to set the parents... | 14:10 |
| quicksilver | that is essentially what I've been doing, yes. | 14:10 |
| quicksilver | except I didn't bother to pull --overwrite wt-dirty | 14:10 |
| quicksilver | I just specified the -r in the bzr merge | 14:10 |
| quicksilver | since it's sufficine for <revno> to excist somewhere in wt-dirty's history to be able to merge it. | 14:10 |
| vila | yeah, sorry looping :) | 14:11 |
| quicksilver | I'm running bzr reconcile in both working trees on a hunch | 14:12 |
| quicksilver | although I'm pretty sure I did that yesterday | 14:12 |
| * vila discovers hunch meaning in that context... | 14:14 | |
| maxb | Personally I think the best way to resolve this would involve hacking on bzr-rewrite until replay could actually follow a branched history | 14:16 |
| vila | maxb: sure | 14:16 |
| vila | bzr-rewrite or fastexport, but we definitely needs a nuke-that-file-yes-I-know-my-history-will-change command | 14:17 |
| doctormo | if remote_branch.bzrdir.spout is used for doing a typical `bzr branch` to get code for modification, what's the equiv code for `bzr checkout` with the lightweight option? | 14:27 |
| Kinnison | remote_branch.create_checkout(targetlocation, revid, lightweight, acc_tree, hardlink) | 14:30 |
| Kinnison | appears to be the critical bit of bzrlib/builtins.py:cmd_checkout():run() | 14:30 |
| quicksilver | vila: OK, I was wrong about one thing. My dirty-wt was in knit format. | 14:31 |
| quicksilver | vila: whilst my clean wt was in CHKCHK format | 14:31 |
| quicksilver | vila: do you think that might have been relevant to anything? | 14:31 |
| vila | quicksilver: well, numerous differences between 0.92 and 2a, so worth retrying the shelve with 2a | 14:32 |
| * quicksilver nods | 14:32 | |
| * vila crosses fingers | 14:33 | |
| quicksilver | I note that reconcile is pretty fast with knit and dog-slow with chkchk | 14:33 |
| quicksilver | the two chkchk reconciles I started are still running. | 14:33 |
| vila | the later is doing far more checks | 14:34 |
| quicksilver | and they've both hit the out-of-memory error | 14:36 |
| quicksilver | even the so-called clean one | 14:36 |
| quicksilver | but even that clean branch has poison in its *repository* | 14:36 |
| quicksilver | just not in a reference revision. | 14:36 |
| quicksilver | so if reconcile touches the non-referenced revisions, that's not surprising. | 14:36 |
| vila | it is | 14:36 |
| * quicksilver wonders how long bzr upgrade will take in the poisoned repo. | 14:40 | |
| doctormo | thanks Kinnison | 14:40 |
| vila | quicksilver: you can try to branch in repo that already contains the poisoned revision... | 14:41 |
| quicksilver | vila: do you think it matters if it's an 'unnamed' combination as long as the repo format is rich root/group cmp/chk inventories? | 14:41 |
| quicksilver | oh, it's done anyway. | 14:41 |
| quicksilver | good | 14:41 |
| vila | hmm, I don't think so | 14:42 |
| quicksilver | vila: bzr: ERROR: Tree transform is malformed | 14:49 |
| quicksilver | so even in 2a, this merge is unshelvable | 14:49 |
| vila | damn | 14:50 |
| === CardinalXiminez_ is now known as CardinalFang | ||
| quicksilver | so, back to plan D. Merge carefully, resolve conflicts carefully. *sigh* | 14:56 |
| vila | quicksilver: can you keep that unshelvable tree somewhere ? | 14:56 |
| quicksilver | vila: I have around 50 copies of it so far :) | 14:58 |
| quicksilver | vila: it seems unlikely I'll lose them all. | 14:58 |
| vila | :-) :-/ | 14:58 |
| === deryck_ is now known as deryck | ||
| teknico | hi esteemed colleagues, everyone :-) got a problem with bazaar, not sure what's going on, any ideas? https://bugs.launchpad.net/ubuntuone-storage-protocol/+bug/506974 | 15:02 |
| ubottu | Launchpad bug 506974 in ubuntuone-storage-protocol "Bazaar traceback when running "make link-sourcedeps"" [High,Confirmed] | 15:02 |
| vila | teknico: did you run 'bzr check' ? | 15:04 |
| teknico | vila, no, I'll do it now in a number of places :-) | 15:04 |
| vila | teknico: also the 'No handlers could be found for logger "bzr"' is... unexpected and may indicate that you can't write to $HOME/,bzr.log which in turn may contain relevant information about the problem | 15:05 |
| teknico | vila, .bzr.log is regularly written to, I looked at it, it doesn't record anything when there's one of those crashes | 15:06 |
| vila | anything relevant or anything at all ? You should at least find your commands there | 15:07 |
| teknico | vila, yes, I meant in that specific cases, it records output for all other commands | 15:08 |
| teknico | in *those specific cases | 15:08 |
| vila | sorry, I should be dumb, you mean it doesn't record that command (but it records all the other ones ?) | 15:09 |
| vila | teknico: ^ | 15:10 |
| teknico | vila, yes, that's what I was trying to say, sorry :-) | 15:11 |
| vila | that means bzr is running under a different uid ? SO maybe it *can't* write to the repo leading to the error | 15:11 |
| teknico | vila, different uid? no, why do you say so? | 15:14 |
| vila | teknico: if it can't write to .bzr.log, something weird is going on like running under a different uid, but there may be other causes | 15:15 |
| teknico | vila, bzr does write to .bzr.log, except when it crashes, it doesn't, but it seems only natural :-) | 15:16 |
| vila | teknico: not at all natural, every command is logged far before a crash can occur | 15:17 |
| teknico | mmm | 15:18 |
| vila | teknico: what is utilities/link-external-sourcecode ? (first line in the traceback) | 15:18 |
| vila | oh wait, you're using bzrlib directly ? | 15:18 |
| vila | teknico: does your script calls bzrlib.trace.enable_default_logging() ? | 15:19 |
| teknico | let me check that script | 15:20 |
| vila | morning jam ;D | 15:20 |
| jam | morning vila | 15:20 |
| teknico | vila, no, it doesn't | 15:21 |
| jam | teknico: then it won't write to ~/.bzr.log :) | 15:21 |
| jam | good catch, vila | 15:22 |
| vila | jam: do you have any idea why a 'bzr uncommit' followed by 'bzr shelve' may crash with bzr: ERROR: Tree transform is malformed [('versioning no contents', 'new-150')] ? | 15:22 |
| jam | vila: well, shelve doesn't handle stuff like changing the tree root id | 15:22 |
| jam | I don't know of other specific reasons | 15:22 |
| jam | the error above looks like it is trying to remove an empty file? | 15:23 |
| vila | something related yes, quicksilver does that rings a bell ? | 15:23 |
| quicksilver | I think there might have been an empty directory | 15:23 |
| quicksilver | I don't think there were any empty files. | 15:23 |
| quicksilver | what is the best way to get the file-id of a file? | 15:23 |
| vila | yeah, better, an empty file *can* be versioned right ? | 15:24 |
| quicksilver | (am now trying to follow through my conflicts) | 15:24 |
| vila | quicksilver: ready to dive into pdb ? | 15:24 |
| vila | oh, for conflicts that's different | 15:24 |
| vila | bzr st --show-ids ? | 15:24 |
| quicksilver | bzr st doesn't seem to say anything about untouched files | 15:25 |
| quicksilver | which is annoying | 15:25 |
| quicksilver | it will tell me the ids of modified or renamed files, yes | 15:25 |
| vila | why would you want to know the file-id otherwise ? | 15:25 |
| quicksilver | so I can work out how a conflict was resolved | 15:26 |
| vila | bzr st -r<right parent>..<trunk> --show-ids | 15:26 |
| quicksilver | it's just one particular files I want the id of | 15:26 |
| quicksilver | (well, two) | 15:26 |
| quicksilver | so I can see which copies got kept and which got renamed. | 15:27 |
| quicksilver | I'll just md5sum them :P | 15:27 |
| vila | going tricky are you ? bzr st -r<right parent>..<trunk> --show-ids FILE | 15:27 |
| jam | quicksilver: bzr inventory file --show-ids I believe | 15:27 |
| jam | or "bzr ls --show-ids" if you can use that | 15:27 |
| === AnMaster_ is now known as AnMaster | ||
| quicksilver | bzr ls only works on directories apparently | 15:28 |
| jam | I think it is supposed to work on more, but is broken for files on Windows at least | 15:28 |
| vila | quicksilver is on OSX | 15:28 |
| quicksilver | bzr inventory works :) | 15:28 |
| quicksilver | thanks jam. | 15:28 |
| vila | jam: can your fix for #494269 be relevant for a case where shelve crashes while commit works ? | 15:32 |
| jam | bug #494269 | 15:32 |
| ubottu | Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269 | 15:32 |
| jam | vila: its a possibility | 15:32 |
| jam | commit can handle root-id changes | 15:32 |
| jam | however, revert pull and update *didn't* either | 15:32 |
| quicksilver | jam: what's a root-id change? | 15:33 |
| quicksilver | how can I deduce whether it applies to my case? | 15:33 |
| jam | quicksilver: it is when the file id assigned to "" changes (the root of your tree) | 15:34 |
| jam | it is unlikely to be the case | 15:34 |
| jam | but if you did "bzr init" 2 times in different directories, and then tried to merge those branches | 15:34 |
| quicksilver | ah, I don't think so, no. | 15:34 |
| jam | it could | 15:34 |
| quicksilver | nope, never did that. | 15:34 |
| quicksilver | this was just a commit which was a big merge | 15:34 |
| quicksilver | (including additions, deletions, renamings and modifications) | 15:35 |
| jam | quicksilver: you're the one hitting "versioning no contents" ? | 15:35 |
| quicksilver | yes | 15:35 |
| quicksilver | I can commit/uncommit it merrily as many times as I want | 15:35 |
| quicksilver | but I can't shelve it | 15:35 |
| quicksilver | which is a shame, because vila's evil hack for replaying merges on an alternate history depends on copying shelves around. | 15:35 |
| jam | I just suspect a bug in the shelve code, not passing something along to the transform | 15:36 |
| jam | specifically, that happens | 15:36 |
| jam | if we call "create_path()" but no "create_contents()" | 15:36 |
| jam | (or create_directory, etc) | 15:36 |
| jam | I don't know exactly how to reproduce, but I'll poke around a bit | 15:36 |
| jam | in the meantime, sounds like a bug :) | 15:36 |
| quicksilver | unfortunately I don't know exactly how to reproduce without giving the repo which I'm not at liberty to do :( | 15:38 |
| jam | quicksilver: it also sounds a little bit like it would involve a file or directory which is deleted in the tree | 15:38 |
| jam | quicksilver: you could at least give the output of "bzr status -r -2..-1" after the commit | 15:38 |
| jam | so we get an idea of what delta the shelver is trying to undo | 15:39 |
| jam | poking around the transform code, the number of places where it would look up the data is pretty convoluted | 15:40 |
| jam | so having a reproducible test case would help tracking down where the bug is | 15:40 |
| vila | jam: it's an uncommit after a merge, 'bzr st' alone should be emough no ? | 15:40 |
| vila | yeah emough :) | 15:41 |
| jam | vila: uncommit + status should be equivalent to commit + status -r -2..-1 | 15:41 |
| jam | Except I don't think the latter mentions pending merges... | 15:41 |
| vila | oh yes, missed the context | 15:41 |
| jam | and adding a pending merge could certainly complicate things | 15:42 |
| vila | jam: quick silver is trying to shelve the changes that represent the merge + the conflicts resolution though which complicate things | 15:43 |
| jam | vila: certainly. I'm pretty sure it is just an edge case that we aren't handling correctly. | 15:44 |
| jam | I'm guessing it is a bug in shelver | 15:44 |
| jam | though, tbh, uncommit/commit don't invoke TreeTransform either | 15:44 |
| jam | a better test is | 15:44 |
| jam | bzr commit | 15:44 |
| jam | bzr branch -r -2 ../other | 15:44 |
| jam | cd ../other | 15:44 |
| jam | bzr pull ../orig | 15:44 |
| jam | since that requires applying the transform to the working tree | 15:45 |
| jam | though I would be pretty surprised if that failed | 15:45 |
| jam | then | 15:45 |
| jam | bzr pull ../orig -r -2 | 15:45 |
| jam | which backs out that change | 15:45 |
| jam | oh | 15:45 |
| jam | you need | 15:45 |
| jam | bzr pull ../orig -r -2 --overwrite | 15:45 |
| jam | (so that it actually steps backwards) | 15:45 |
| vila | yeah, sounds like what quicksilver is doing, then, bzr uncomit and from there commit works shelve crashes | 15:46 |
| teknico_ | vila, "bzr check" pointed out another problem, not sure it's related though: https://bugs.launchpad.net/bzr/+bug/507040 | 15:52 |
| ubottu | Launchpad bug 507040 in bzr "Crash during "bzr check"" [Undecided,New] | 15:52 |
| === deryck is now known as deryck[lunch] | ||
| vila | teknico_: the missing antoniolenton@gmail.com-20090420134023-q7gh2mem413kr4iz is from 2009/04/20, any conversion since then ? Any stacked branch involved ? | 16:00 |
| teknico_ | vila, yes, we converted the repo to 2a format a few months ago, and yes, that repo is a top stacked one | 16:02 |
| vila | teknico_: can you attach the relevant .bzr.log part to the bug ? | 16:03 |
| teknico_ | vila, there's only the same traceback that's already in the crash log | 16:05 |
| vila | teknico_: is it the same repo than bug #506974 ? Oh damn, I thought check outputs more details in .bzr.log | 16:06 |
| ubottu | Launchpad bug 506974 in ubuntuone-storage-protocol "Bazaar traceback when running "make link-sourcedeps"" [High,Confirmed] https://launchpad.net/bugs/506974 | 16:06 |
| vila | teknico_: and is it the only repo failing the check ? | 16:06 |
| === beuno is now known as beuno-lunch | ||
| teknico_ | vila, no, it's not the same repo, and the check stops at that error, no other errors previously | 16:07 |
| vila | teknico_: can you do 'bzr st -c revid:antoniolenton@gmail.com-20090420134023-q7gh2mem413kr4iz' ? | 16:09 |
| teknico_ | vila, output: bzr: ERROR: No WorkingTree exists for "file:///home/nl/canonical/ubuntuone/.bzr/checkout/". | 16:10 |
| vila | meh, can you do it from a working tree ? Or do 'bzr diff -c revid:antoniolenton@gmail.com-20090420134023-q7gh2mem413kr4iz' instead ? | 16:11 |
| vila | I'm just trying to verify if we can access that revision one way or another | 16:12 |
| vila | s/verify if/verify that/ | 16:12 |
| teknico_ | now it's: bzr: ERROR: Not a branch: "/home/nl/canonical/ubuntuone/.bzr/branch/". | 16:12 |
| teknico_ | it's the top of a stacked repo, there's no working tree of it | 16:13 |
| === sdboyer is now known as sanchopanza | ||
| === sanchopanza is now known as sdboyer | ||
| NfNitLoop | Hrmm, is Hrmm, is 'bzr svn-push' now just 'bzr push <svnURL>'? | 16:14 |
| vila | teknico_: there should be some branches below, go in any of them, I can't see which one is involved (that may be in .bzr.log though) | 16:14 |
| teknico_ | vila, the error in #507040 is in the top repo | 16:16 |
| teknico_ | however, I'm more interested in the error in #506974 | 16:16 |
| vila | teknico_: can you explain your layout a bit ? Are all your branches sharing the same repo with branches stacked on different branches ? | 16:18 |
| NfNitLoop | Hrmm, is there a way to see a log of the pending merges? | 16:19 |
| vila | teknico_: did you had the bzrlib.trace.enable_default_logging() call to your script ? Did that outputs something in .bzr.log ? | 16:19 |
| teknico_ | vila, no, the script does not call that | 16:19 |
| vila | NfNitLoop: 'bzr st -v ' ? | 16:20 |
| vila | teknico_: can you add it then so we know what it is trying to say when the 'no loggers found' message is emitted ? | 16:20 |
| teknico_ | vila, I have a top ubuntuone stacked repo, and below it there's trunk, and other branches branched from trunk | 16:20 |
| teknico_ | the error in #506974 is in a completely different repo | 16:21 |
| === Adys_ is now known as Adys | ||
| NfNitLoop | vila: that shows me a one-line summary of the commit messages... | 16:24 |
| NfNitLoop | not the full commit. Nor the files changed in that commit. | 16:25 |
| NfNitLoop | I sortof want 'bzr log -v' behavior, but on the commits I merged in. | 16:25 |
| NfNitLoop | but they hvaen't been committed locally yet, so they don't seem to show up in bzr log. | 16:25 |
| vila | NfNitLoop: is 'bzr qlog' an option ? | 16:26 |
| NfNitLoop | Oh well. I know where they occurred in the source branch so I just did bzr log on that. But if history had been odd, that would've been a pain. :p | 16:26 |
| teknico_ | vila, thanks for the help, I have to go now | 16:26 |
| vila | teknico_: update the bugs if you collect more info | 16:27 |
| teknico_ | vila, I will | 16:27 |
| NfNitLoop | qlog is nice. Though, will it show pending merges? *Shrug* too late, already committed. :p | 16:27 |
| NfNitLoop | Sooo glad I got bzr-svn working with our repo. :p | 16:30 |
| jam | vila: what is the status of https://code.edge.launchpad.net/~kamil-szot/bzr/non-ascii-chars-in-ftp-filenames/+merge/17012 | 16:34 |
| jam | I'd like to knock it out of the review queue, but are we waiting for feedback from kamil? | 16:34 |
| jam | vila: also, can you give a second review on https://code.edge.launchpad.net/~nmb/bzr/script-test-mv/+merge/17269 ? | 16:35 |
| vila | jam: I think it's fine putting kamil's mp to wip while waiting for feedback | 16:36 |
| jam | well, I'm thinking it really needs "Rejected" since we fixed it a different way | 16:36 |
| jam | (that way WIP doesn't get full) | 16:36 |
| jam | I hesitate to wield the big hammer, though | 16:37 |
| rubbs | NfNitLoop: if you do a qcommit rather than commit it will show pending merges. | 16:37 |
| vila | yeah, then a comment explaining that it's rejected because the tried approach is not appropriate then to make the hammer softer :D | 16:37 |
| vila | NfNitLoop: yes it shows pending merges, I use it a lot when merging up to copy/paste part of the commit messages | 16:38 |
| jam | vila: well, I'd like confirmation that upload + ftp is actually fixed | 16:39 |
| vila | jam: the test I *added* to bzr-upload should cover that for bzr-core, all the transport methods used there are now covered | 16:40 |
| vila | jam: I (wrongly) relied on bzr test suite for the first patch | 16:40 |
| jam | vila: what is the missing bzrlib test ? | 16:41 |
| jam | It sounds more like bzr-upload was supplying an invalid path | 16:41 |
| vila | it was suppyling unicode paths instead of urlutils.escape()'d paths | 16:41 |
| jam | which, tbh, was probably part of the original design (4?) years ago | 16:42 |
| jam | I spent a lot of time making Transport work with non-ascii | 16:42 |
| jam | only to end up with us never using it in bzrlib ... | 16:42 |
| vila | so there are no missing tests in bzr since we use ascii paths... wait... we *may* add more tests that we support unicode paths for the directories containing the branches... | 16:42 |
| vila | jam: I think some users may use it for their path to .bzr | 16:43 |
| jam | vila: the root path should be a URL | 16:43 |
| jam | and we ~ don't care | 16:43 |
| jam | it should work | 16:44 |
| jam | but Transport shouldn't directly be munging that part of the URL | 16:44 |
| jam | (I think...) | 16:44 |
| jam | anyway, for HTTP transports we wanted to make sure not to touch anything but the part we control | 16:44 |
| vila | it doesn't but it should receive url encoded paths, bzr-upload was violating that assumption | 16:44 |
| === deryck[lunch] is now known as deryck | ||
| === beuno-lunch is now known as beuno | ||
| vila | oh no, where is my day gone !!! | 17:25 |
| vila | jam: reviewed and pqm'ed | 17:25 |
| fullermd | I ate it. I'm sorry. | 17:28 |
| quicksilver | vila: I ate it with my demon repo, sorry. | 17:28 |
| vila | quicksilver: how is it going ? | 17:29 |
| quicksilver | vila: I've had other things to do in the mean time, but a hybrid replay/merge/rsync approach looks like it will work. | 17:29 |
| vila | shame we can't do better :-/ | 17:29 |
| quicksilver | seems like "repacking texts" results in the occasional very slow commit. | 17:36 |
| vila | quicksilver: that's expected, should occur every 10, 100, 1000 commits, look at .bzr/repository/packs sorted by size and you should get the idea | 17:37 |
| * quicksilver nods | 17:37 | |
| quicksilver | fine, just checking | 17:38 |
| quicksilver | well remarking rather than checking | 17:38 |
| quicksilver | vila: initially disconcerting because I worried that it indicated I had actually merged the poison in since it was so slow | 17:38 |
| * vila nods :D | 17:39 | |
| quicksilver | vila: always takes me longer than I'd like to discover the correct selection of rsync options, too. For some reason I'm unable to remember rsnc commandline syntax | 17:40 |
| vila | quicksilver: me neither, that's why I put them in scripts and under version control | 17:41 |
| vila | but I'd bet you want to start with '-av --delete' here and then carefully read the help about what -a is aliased to :) | 17:43 |
| quicksilver | I didn't want a, in fact. | 17:45 |
| quicksilver | -i --checksum --delete | 17:45 |
| quicksilver | --dry-run, of course | 17:45 |
| quicksilver | -r | 17:45 |
| quicksilver | oops. the bad file is in the repo, this repacking is throwing memory errors | 17:47 |
| quicksilver | hopefully it's just garbage | 17:47 |
| * quicksilver branches to test | 17:48 | |
| vila | jam: can any of your memory fixes be relevant here ? A repack, even with a 600M object shouldn't reach the 2GB peak no ? | 17:49 |
| quicksilver | curiously the repack does succeed even with the error | 17:49 |
| vila | quicksilver: the poison is a *text* file right ? And the size is ? | 17:50 |
| quicksilver | well it claims to succeed | 17:50 |
| quicksilver | vila: yes, 600M text. | 17:50 |
| quicksilver | vila: phew. branching it has sane size. the posion is not in a reference revision ;) | 17:59 |
| vila | \o/ | 17:59 |
| rubbs | well done | 18:22 |
| * rubbs applauds. | 18:22 | |
| vila | quicksilver: was it the final reconstructed branch or just an intermediate one ? | 18:33 |
| === methods is now known as Guest42852 | ||
| cody-somerville | everytime I commit a change, I get an error about inconsistent details in skipped record. | 19:15 |
| cody-somerville | http://pastebin.ubuntu.com/356189/ | 19:16 |
| NfNitLoop | Are there any major differences between 'bzr checkout' and 'bzr checkout --lightweight' if you're checking out from and into the same shared repository? | 19:32 |
| NfNitLoop | My assumption is... no. :p | 19:32 |
| quicksilver | vila: almost final. | 19:32 |
| quicksilver | vila: no merges left so remaining replays should be trivial. I just got busy. | 19:33 |
| doctormo | How would I get the parent_location or transport from a branch? | 19:53 |
| NfNitLoop | Yay, think I got another coworker interested in using bzr(-svn) here. :) | 20:23 |
| * NfNitLoop just wrote a wiki page with recommended workflow for working w/ our repo. | 20:23 | |
| NfNitLoop | I had to make some tiny changes to allow working with our SVN repo. | 20:25 |
| NfNitLoop | I Just stripped the places that check for backslashes in file names. | 20:26 |
| NfNitLoop | since at one point in history we had a file in the repo with backslashes in its name. | 20:26 |
| NfNitLoop | https://code.launchpad.net/~cody-casterline | 20:26 |
| NfNitLoop | are my changes. | 20:26 |
| NfNitLoop | Someone said they might break other things, but I haven't had a chance to look into that very deeply. | 20:27 |
| NfNitLoop | the test suite didn't seem to find any errors with it. (There were some test failures, but for seemingly unrelated things that I think we're failing in the upstream branch too.) | 20:27 |
| === _mm-mysql is now known as mm-mysql | ||
| === davidstrauss is now known as davidstrauss-afk | ||
| jfroy|work | jelmer: greetings, any words on https://bugs.launchpad.net/bzr-svn/+bug/505049? | 20:40 |
| ubottu | Launchpad bug 505049 in bzr-svn "VersionedFileInvalidChecksum exception while branching remove svn branch" [Undecided,New] | 20:40 |
| jfroy|work | I actually did a bit of experimentation by hacking bzr-svn to use a different prop prefix, and that didn't solve the issue, so it's probably not a bad revprop issue | 20:41 |
| jelmer | jfroy|work, I'll have a look when I have a spare moment | 20:43 |
| jfroy|work | jelmer: thanks, let me know if you need more data, and sorry to be annoying about it | 20:44 |
| jam | vila: late answer, but I didn't fix the peak memory issues for "pack" | 20:47 |
| jam | the pack code creates an index which can take a significant amount of mem | 20:47 |
| jam | it is on my TODO, but is unfortunately pretty low | 20:47 |
| maxb | What are the circumstances in which bzr-svn needs to build a fileidmap knit? | 20:48 |
| maxb | For some of my repositories it has done so, for others not. | 20:48 |
| maxb | I'd like to know how to provoke it, so I can let it run overnight on a huge repository | 20:48 |
| NfNitLoop | Hrmm, maybe it only happens on repos that directly interact with svn? | 20:49 |
| jml | can bzr be tricked into preserving timestamps | 20:52 |
| doctormo | I would like to detect if changes have been made to a working branch, a cheap boolean would be most effective. | 21:13 |
| doctormo | But I can't figure anything out other than making an entire change tree. | 21:13 |
| rubbs | doctormo: would bzr status work? or am I missunderstanding your question? | 21:17 |
| doctormo | rubbs: sorry I should have specified, using bzrlib | 21:17 |
| rubbs | ah, then I will be no help | 21:17 |
| beuno | doctormo, | 21:17 |
| beuno | something like | 21:17 |
| beuno | changes = wt.changes_from(wt.basis_tree()) | 21:18 |
| beuno | if revision is None and changes.has_changed(): | 21:18 |
| beuno | return True | 21:18 |
| beuno | or something | 21:18 |
| beuno | wt being the working tree | 21:18 |
| doctormo | wt is the working tree I guess and revision is the branch.last_revision() | 21:19 |
| beuno | right | 21:20 |
| beuno | should be more robust if you check for at least one commit | 21:21 |
| doctormo | I'm wondering if the best way to get than is branch.basis_tree() | 21:21 |
| doctormo | apparently wt.changes_from(wt) is unimpressive, so I guess there is a way to get a wt of what exists. | 21:24 |
| doctormo | (wt, wt_path) = workingtree.WorkingTree.open_containing(path) | 21:25 |
| doctormo | Hmm I can see removals, additions and changes... but not unversioned files | 21:31 |
| doctormo | Ah I guess you get those from wt.unknowns() | 21:33 |
| beuno | doctormo, correct | 21:36 |
| === davidstrauss-afk is now known as davidstrauss | ||
| poolie | good morning! | 22:15 |
| jelmer | poolie: Hello! | 22:16 |
| poolie | hi | 22:16 |
| poolie | are you in nz? how's it going? | 22:16 |
| mwhudson | poolie: jelmer is navigating the bowels of the soyuz data model | 22:17 |
| mwhudson | he might be back soon | 22:17 |
| jelmer | poolie: Yep, hacking on building from branches :-) | 22:17 |
| poolie | heh, with an endoscope? | 22:17 |
| === ereslibre_uni is now known as ereslibre | ||
| mkanat | What's the proper way to get the on-disk path of a bzr branch, given a Branch object? | 22:25 |
| mkanat | Or, barring that, is there any string that I could get out of a branch object to uniquely identify it (even if it gets updated)? | 22:26 |
| poolie | branch.transport.base | 22:26 |
| mkanat | poolie: Awesome, thank you. | 22:26 |
| poolie | nb there is also .has_same_location() | 22:26 |
| poolie | um | 22:26 |
| poolie | add extra underscores as needed | 22:27 |
| poolie | this should be made a bit simpler and more consistent | 22:27 |
| jml | bzr: ERROR: unknown command "cp" | 22:56 |
| jml | fail | 22:56 |
| mkanat | poolie: Is there a more correct way to get branch._transport from an external program than to just access it directly? | 22:58 |
| poolie | jml, that's our most affecting bug | 22:58 |
| jml | heh heh | 22:59 |
| poolie | mkanat: no; we should rename it to be pubilc | 22:59 |
| mkanat | poolie: Okay. Is it safe to have loggerhead depend on its current private name, though? | 22:59 |
| poolie | yes | 23:00 |
| mkanat | poolie: Okay, thanks. :-) | 23:00 |
| spiv | Good morning. | 23:07 |
| maxb | Why does locations.conf override direct config in a branch's branch.conf? This seems a bit odd | 23:09 |
| maxb | Mainly because it then becomes impossible to have special cases within an appendpath tree | 23:09 |
| Peng | maxb: Try puttig the branch's config in locations.conf too? | 23:21 |
| mkanat | mwhudson: Okay, I submitted a merge proposal for a possible fix for the codebrowse hangs. | 23:32 |
| mwhudson | mkanat: woo | 23:34 |
| mkanat | maxb: I think it makes sense to have locations.conf override the branch configuration, because locations.conf is per-user, no? | 23:34 |
| Peng | mkanat: Ooooh, neat. | 23:35 |
| maxb | hmm... I guess... I don't have any multiuser branches that have any branch.conf setttings | 23:35 |
| Peng | mkanat: Why does line 21 of LP's diff end with a ";"? :D | 23:35 |
| mkanat | Peng: Ahh, silly habits. :-) | 23:35 |
| mkanat | Peng: Probably just did that totally unconsciously. | 23:35 |
| poolie | hello spiv | 23:36 |
| Peng | Would using cache_key in revision_graph_locks work? | 23:36 |
| mkanat | Peng: Oh, instead of using the branch thing? Yeah, that would probably make more sense. | 23:36 |
| Peng | mkanat: This doesn't matter, but you don't need to declare revision_graph_locks global. | 23:37 |
| mkanat | Peng: Oh, right, because I'm not instantiating it? | 23:37 |
| mkanat | Peng: This honestly is the first time I've had to explicitly use thread locking, and I almost never use global data structures for any reason, so.... :-) | 23:38 |
| Peng | mkanat: You only have to declare a variable as global if you rebind it (foo = bar). | 23:38 |
| mkanat | Peng: Right. | 23:39 |
| Peng | Writing to a dict is just accessing foo.__setitem__. | 23:39 |
| mkanat | Peng: For these sorts of review fixes, is it more traditional to uncommit and re-push, or to simply do another commit to address the review issues and then push? (This is my first merge proposal in any Canonical process.) | 23:39 |
| mkanat | Peng: Yeah, that I know. | 23:39 |
| Peng | mkanat: I'd do a second commit. | 23:40 |
| mkanat | Peng: Okay. | 23:40 |
| Peng | That seems to be standard practice here. | 23:41 |
| Peng | "bzr log lp:bzr | grep -i review" :P | 23:42 |
| mkanat | Peng: Any other comments? | 23:44 |
| mwhudson | mkanat: don't uncommit unless you really have to | 23:45 |
| mkanat | mwhudson: Okay. | 23:46 |
| mwhudson | mkanat: +"""Used to store locks that prevent mulitple threads from building a | 23:46 |
| mwhudson | 17+revision graph for the same branch at the same time, because that can | 23:46 |
| mwhudson | ... | 23:46 |
| mwhudson | mkanat: should be a comment, not a string? | 23:46 |
| mkanat | mwhudson: I was thinking so probably, too. | 23:46 |
| Peng | It looks like this adds a second call to update_missed_caches()? Was that intentional? | 23:47 |
| mwhudson | mkanat: did you consider pushing the locking into compute_whole_history_data ? | 23:47 |
| Peng | I don't really know this code, so I can't say anything for sure... | 23:47 |
| mwhudson | Peng: i think that's just the diff being a bit odd | 23:47 |
| mkanat | mwhudson: I did...there was some reason I didn't...oh yes, because we don't have the cache within that method. | 23:48 |
| mwhudson | mkanat: ok | 23:48 |
| Peng | mwhudson: It's not. | 23:48 |
| mwhudson | Peng: there are two calls before and two calls after, i think? | 23:49 |
| Peng | Err, wait. | 23:49 |
| Peng | Wait, I, uh. Yeah, you're right. | 23:49 |
| Peng | This locks even if it doesn't end up calling compute_whole_history_data(), doesn't it? Is that a problem? | 23:51 |
| mkanat | Peng: It does. It wasn't a problem in my testing. | 23:51 |
| mkanat | Peng: The logical problem is that we must lock before checking if there's a cached revision graph. | 23:51 |
| mkanat | Peng: I mean, we don't *have* to--I could refactor things to avoid it. | 23:52 |
| Peng | It'd be more complicated to do it that way, and not really worth it, right? | 23:52 |
| mkanat | Peng: Yeah, I think so. | 23:52 |
| mkanat | It'd be one of those check, lock, check, run things. | 23:53 |
| Peng | Fun. | 23:53 |
| mkanat | Loggerhead is still considerably slower under massive simultaneous load than it is under a light load, but I couldn't get it to demonstrate the hanging level of slowness that I was seeing before. | 23:55 |
| Peng | Is there a race condition when creating the lock? Is it possible that another thread could create a lock between "if ... in ..." and "... = Lock()"? | 23:56 |
| mkanat | Peng: I thought about that. Logically, yes. Practically, because of the GIL, no. | 23:56 |
| mwhudson | still | 23:56 |
| mwhudson | using defaultdict would be better here no? | 23:56 |
| mkanat | At least, practically, it's unlikely. I could avoid it with another lock though. | 23:56 |
| mwhudson | mind you, 2.5 only | 23:56 |
| Peng | Ick. | 23:57 |
| mwhudson | or setdefault, but then you'll end up creating a lock for every request | 23:57 |
| mkanat | mwhudson: What version do we require now? | 23:57 |
| mwhudson | mkanat: 2.4 | 23:57 |
| Peng | mkanat: 2.4 | 23:57 |
| Peng | Oops. | 23:57 |
| mwhudson | but launchpad is on 2.5 so i care a lot less now :) | 23:57 |
| mkanat | Yeah, but RHEL 5 is 2.4.... | 23:57 |
| mkanat | That's sort of what I generally use as a limiter for stuff that's really hard to reinstall at a base OS level. | 23:58 |
| Peng | bzr still supports 2.4, but that doesn't really stop Loggerhead from dropping it. | 23:58 |
| mkanat | mwhudson: A simpler solution is to put another lock around the check. | 23:58 |
| Peng | If we wanted to, anyway. Loggerhead obviously has fewer users than bzr, but more of its users will be on old server installs... Meh. | 23:59 |
| mkanat | mwhudson: The only problem is that that lock totally synchronizes loggerhead, because it would be one global lock. It's pretty short, though. | 23:59 |
| mwhudson | mkanat: simpler, but more expensive i guess | 23:59 |
| mkanat | mwhudson: Yeah. | 23:59 |
| Peng | _I_ don't run 2.4, so I don't care much, but... | 23:59 |
| Peng | mwhudson: Launchpad is on 2.5? | 23:59 |
| * mkanat runs 2.4 on all his servers. | 23:59 | |
| mwhudson | if we hit this race, i guess it's possible to end up in the bad old situation of building multiple caches | 23:59 |
| mwhudson | Peng: yes! finally | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!