[00:00] vila: still up? [00:25] greetings, newb here failing to properly setup bazaar server on localhost. [00:26] This is what I do to setup bazaar server: "sudo bzr serve --directory=files/servers/bazaar/ --bzr" [00:26] you probably don't want the server running as root [00:26] See... I'm that bad. :-) [00:26] I mean bad as in notknowing. [00:27] PureRumble: I agree with lifeless, but that command should still work [00:27] Ok, so I will not run as sudo. bad idea. bad idea! :-] [00:29] Ok but there are still problems. So now I no longer run server as root. [00:30] PureRumble: what problems? What error are you getting? [00:30] But still when I do "bzr push bzr://localhost/test" I get "bzr: ERROR: Transport operation not possible: readonly transport" [00:30] PureRumble: right [00:30] PureRumble: you need to explicitly pass --allow-writes to bzr serve if you want to allow that [00:31] see, it's that easy! :-) [00:31] PureRumble: (in which case it's a really good idea not to run it as root!) [00:32] PureRumble: you may want to create a user on your system just for bzr serve [00:32] 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] PureRumble: connect, and write to! [00:33] PureRumble: Why do you want to run a server? [00:33] ok, so something tells me that is not good and needs to be taken care of :) [00:33] You don't need one to create branches. [00:33] Because, I thought it would be better than storing stuff in .bzr folders, but perhaps I'm wrong? [00:33] You don't need a bzr server for that. [00:34] If it's just you, locally, don't bother with bzr serve. [00:34] Just run bzr directly. [00:34] But then stuff would be stored in .bzr-folders, is that a good idea? *non-rethorical question* [00:34] e.g. instead of "bzr push bzr://localhost/test", you can do "bzr push files/servers/bazaar/test" [00:35] I'm not sure what you mean by .bzr folders. [00:35] How can I find out what revision a file in my tree was last changed? [00:35] I thought blame would do it, but that seems to be an alias for annotate [00:35] bzr log -l1 filename ? [00:36] 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] bob2, cheers though. [00:36] ahh [00:37] PureRumble: I think maybe you're talking about the difference between a treeless branch and branch with a colocated working tree. [00:38] is it possible to uncommit a revision that isn't the tip? [00:38] actually, nevermind, I don't think I want to do that [00:39] 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] idnar: good, because you can't (without also uncommitting the revisions between it and tip) [00:40] 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] idnar: you can reverse the changes made by a particular revision, though. [00:40] (and commit that) [00:40] PureRumble: you can access bzr branches via SFTP and SSH [00:40] PureRumble: you don't need a special bzr server to do that, just allow SSH access. [00:42] spiv: that causes problems if you want to put the changes back later [00:42] 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] idnar: no more than the reversing [00:44] PureRumble: the most secure way is via bzr+ssh [00:44] https://bugs.edge.launchpad.net/bzr/+bug/152008 [00:44] Launchpad bug 152008 in bzr "Ability to unmerge or revert a merge sensibly" [Wishlist,Triaged] [00:44] idnar: I'm talking about a cherrypick merge; e.g. "bzr merge . -r 99..98 && bzr ci -m 'Undo r99'" [00:44] PureRumble: install opensshd [00:44] I believe that bug covers what I'm talking about [00:46] idnar: right, including the merge . -r recipe. [00:47] ... Ahaaaa, so you mean I should connect through opensshd and just navigate to the same dir and continue working? [00:47] 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:48] that's the default [00:49] 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] 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] PureRumble: you can do that, but you can also use commands like "bzr branch bzr+ssh://yourhost/path/to/your/branch" [00:50] mmj8237: you pushed to a file:/// url [00:51] mmj8237: "remote" in that context just means "connected via a network URL than a local file path" [00:51] mmj8237: they aren't 'remote' [00:51] 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:52] 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] ok so I'll install openssh-server... but will I need the client too? [00:53] PureRumble: only if you need to connect to the server ;) [00:53] 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] I'm not very good at this, no not at all :-/ [00:54] mmj8237: yeah, we should probably add --no-tree to 'bzr push', 'bzr branch' had that added relatively recently. [00:54] cool [00:54] 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] mmj8237: file a bug? :) [00:55] 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:56] Though if you had other suggestions I'd be all ears :) [00:57] 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:58] poolie: http://rproxy.samba.org/ has a stale link to http://samba.org/~mbp/superlifter/ [00:58] 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] So if the branch's absolute path is /home/foo/bar, do I do "bzr diff bzr+ssh://localhost/home/foo/bar" ? [00:59] mmj8237: but I guess it depends on how much being able to completely delete unwanted revisions can save you space. [00:59] PureRumble: typically no [00:59] PureRumble: you generally only diff locally - 'bzr diff' [00:59] ok but that was just an example. [00:59] PureRumble: but that url is correct [01:02] Ok, it actually works! But a bit annoying to print the password each time I wanna do something.... :-/ [01:03] PureRumble: you can use an agent to remember the password or passphrase (if you use ssh keys) [01:06] 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] Launchpad bug 506730 in bzr "Add --no-tree to bzr push" [Undecided,New] [01:07] mmj8237: thank you! [01:08] Ok thanks, so now things seam to be working smoothly. [01:09] But how can I restrict what users can connect to my bzr server if I want to have such a server? [01:09] the plain bzr:// protocol doesn't have authentication or access control [01:09] if you need that, use bzr+ssh or bzr+http [01:11] 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] 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] they use bzr+ssh [01:12] 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:13] spiv: but that would be a problem if the files happen to be on ntfs, right? [01:15] PureRumble: I wouldn't think so, ntfs has file permissions too. [01:15] ACLs even! :) [01:17] (But I don't have much experience with managing ntfs from linux) [01:17] yeah i knew that, i'm not that bad :-(. Just didn't think linux can modify them. [01:19] General question: what do you suggest for managing php project (with revision control) remotely? [01:22] 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] PureRumble: maybe the bzr-upload plugin or the bzr-push-and-update plugin would help. [01:27] 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] Pardon newbie questions. [01:35] Well, you could do that with ssh. [01:35] I'd also expect it to be relatively easy to write a server-side bzr plugin that ran your buildsystem for every commit. [01:36] or use e.g. hudson [01:37] so much knowledge outside my brain, so little inside it! googling hudson [01:37] hudson-ci.org [01:38] PureRumble: thats for doing build testing [01:39] 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:49] 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] hostA and hostB different computers connected to web. [01:51] 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] So like if I write some file to /foo/magic, ssh makes sure it is written remotely to /bar/magic on hostB. [01:52] 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:53] PureRumble: You can do that (at least in linux), but why do you want to? [01:53] So I can easily manage stuff remotely of course :-) [01:54] RAOF: Fuse (hence sshfs) exists for BSD too :p [01:54] 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] chx: And I think MacFUSE exists, too :P [01:54] RAOF: not to mention the opensolaris port. [01:55] 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] jacseen: Bah. Sorry, I should have read your question more thoroghly. [01:55] jacseen: also, if you can upgrade to bzr >= 2.0 you'll find things work faster. [01:55] and Dokan on Windows. [01:56] 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] AfC, how does one upgrade to bzr 2.0 in, say, Ubuntu 9.10? [01:56] 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:57] mac9416: use the bzr PPA [01:57] jacseen: I think you need a newer version of bzr [01:57] deb http://ppa.launchpad.net/bzr/ppa/ubuntu karmic main [01:57] AfC, gracias. [01:57] that has the latest stable release. [01:59] 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] 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? [02:00] Now what do you propose I do on laptop to continue working? [02:01] 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] jacseen, create a repository to place all your branches in [02:02] 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] PureRumble: Right. [02:03] 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] 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:05] 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:09] Unless you run a webserver on your laptop, right. [02:15] 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:21] 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:22] jacseen: you can use 'bzr upgrade' to downgrade too [02:23] 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] spiv by passing the format in cmdline. OK thanks [02:24] spiv that's what I was trying to confirm. Makes sense. [02:25] what is launchpad 'branch format 7' really in bzr terms? [02:28] 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] jacseen: it's the repository format that is usually the problem [02:29] 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:30] spiv and here I thought I had it almost figured out :P [02:48] * igc heads off for a few days of holidays [02:50] thank you all for the added information, eventually I'll know everything again. :p [02:51] jacseen, then will come another big upgrade. :-) [03:38] here's a quiz [03:38] 42 [03:40] what's going on here: http://pastebin.ubuntu.com/355857/ [03:44] poolie: ping [03:45] pong [03:45] poolie: I have a bug [03:45] poolie: see mwhudson's paste [03:45] poolie: I'm trying to work out a summary [03:45] poolie: the actual branches in the pastebin have moved [03:45] poolie: but I have kept the branch for bug triage [03:45] poolie: it is now lp:~launchpad-pqm/bzr-hg/broken [03:46] if in doubt, file a bug with the exception and the innermost function name [03:46] from -Derror [03:46] ok [03:46] with that stuff in the subject line, i mean [03:46] and the tracebac in the description [03:48] poolie: https://bugs.edge.launchpad.net/bzr/+bug/506777 [03:48] Launchpad bug 506777 in bzr "InvalidRevisionSpec: Requested revision: u'281' does not exist in branch" [Undecided,New] [03:54] ok [03:58] thumper: is this urgent? [03:58] poolie: no, I've worked around by making an unstacked branch [03:58] high?medium? [04:04] on the whole, it seems a little broken, so high [04:04] but I also have that feeling about committing to a stacked branch [04:06] what, that you can't ? :) [04:10] thumper: just in case jelmer did something weird in the history it might be useful to check that branch before pushing [04:10] poolie: it works for an unstacked branch [04:10] i'll have a bit of a poke at it [04:10] lifeless: EPARSE [04:12] thumper: commit to a stacked branch. [04:13] 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] thats right [04:14] we want to commit directly to the branch [04:14] we now have at least two different use cases in LP for this [04:16] cool [04:16] would love to see that fixed ;) [04:26] poolie: how do I go about increasing the priority of that? [04:27] which one? commit to a branch or log? [04:28] commit to a stacked branch (bug 375013) is already marked High, FWIW. [04:28] Launchpad bug 375013 in rosetta "Cannot commit directly to a stacked branch" [High,Triaged] https://launchpad.net/bugs/375013 === Sam__ is now known as SamB_XP [04:48] what does it mean when bzr claims a branch is 'format: unnamed'? lp:~keryx-admins/keryx/devel/ [04:49] from 'bzr info'. [04:50] what format should I use for a repo/branch in order to make it the same format to ease the merges? [04:54] jacseen: try 'bzr info -v' [04:54] 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:55] jacseen: in this case, [04:55] jacseen: --2a (i.e. the default format that bzr 2.0 creates) is fine [04:55] still 'format: unnamed' [04:56] alright [04:56] 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] 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] Oookaaay, I won't try to understand taht one yet [04:57] jacseen: as a workaround, you can use 'bzr info nosmart+lp:~keryx-admins/keryx/devel/' :/ [04:57] jacseen: sorry about that bug [04:57] Format: [04:57] control: bzr remote bzrdir [04:57] branch: Remote BZR Branch [04:57] repository: bzr remote repository [04:58] Yeah, the 2.1 betas do a little better there. [04:58] my main concern is, will my branches in 2a format cause extra headaches when merging back into the branches upstream? [04:58] jacseen: no, 2a is exactly the right format [04:58] jacseen: that branch is in fact in 2a format [04:59] jacseen: there's just a bug with bzr info that stops that from being obvious :( [04:59] jacseen: upstream of what ? [04:59] jacseen: just to be clear, "upstream" here == lp:~keryx-admins/keryx/devel/, yes? [04:59] is that why my bzr 1.16 complained bitterly about rich-root when I tryed merging pack-0.92 into that one? [05:00] spiv yes on the upstream currently [05:01] 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] hmm interesting, I thought I was going that direction [05:01] 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:04] 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:05] but I upgraded to bzr 2.0.3, so now my branches are all 2a, so that should help my side [05:05] Yes, sounds like it should :) [05:05] Things should be faster now, too :) [05:07] spiv: great so now I have to finish rebranching all keryx branches and translate my code changes over. No problem. Solution found [05:07] spiv: thanks [05:07] jacseen: you're welcome, glad I could help. [05:26] hi spiv, all === EdWyse_Mobile1 is now known as EdWyse_Mobile [07:04] hi all [07:06] Hmm, I think I'm close to having a working NEWS file merge plugin. [07:23] heya bzr [07:24] Woo, it works. [07:25] So, that's a useful proof-of-concept for the per-file merge hook. [07:25] Also shows where things are a bit more cumbersome than necessary. [07:25] * spiv submits [07:41] Ok, merge proposal submitted. I'm done for the day. [07:44] cheerio spiv [07:44] hope we see you tomorrow :) [07:44] hi vila [07:44] poolie: who knows! :) [07:50] hey poolie ! Thanks for your feedbackS on conflicts, replying now [07:50] thanks [07:50] i hope that didn't sound too critical [07:51] nope, never :) [07:56] The problem domain is complex anyway, so it's hard to find the small steps :) [07:59] well, goodnight [08:16] vila: good morning [08:16] good morning quicksilver [08:17] I think I read you had a solution but not what that solution was :) [08:17] vila: I believe I have an approach which solves my problem. [08:28] quicksilver: and the approach is ? [08:32] vila: after the manually fixed poison revision, proceed up the history tree of the old (poisoned) branch [08:32] vila: for each revision which is merely a plain commit, use bzr replay to replay it. [08:32] for each merge do the following: [08:32] 1. bzr merge -r"revid:exact-revid-of-merge-source" [08:32] 2. bzr revert . # discard those changes but keep them registered [08:33] 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] 3. patch -p0 < my.diff # apply most of it [08:35] 5. for i in `egrep '^=== added' my.diff | awk -F"'" '{print $2}'`; do bzr add $i; done; # record the added files as added [08:36] That should work except for the renames [08:36] 6. manually process any binary files added or changed using bzr cat (binary files don't get included in the diff) [08:37] and the binary files, yes, 'bzr shelve' should help if called at the right time [08:38] spiv: cool! (re per-file merge) [08:38] 7. egrep '^=== renamed' to identify any renames and process them by hand [08:38] hi spiv, vila [08:38] hi bialix [08:41] vila: I thought about bzr shelve but couldn't work out how to use it for this. [08:42] 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:45] the poisoned revisions appears in the history of the branches you are merging from right > [08:45] s/>/?/ [08:47] vila: no, they don't [08:47] I don't understand why you do 2. bzr revert then [08:53] vila: because the merge causes large, complex conflicts. [08:53] vila: and the original developer resolved them [08:55] ha, yes, of course [08:55] and I want to use his resolution, which lies in that diff. [08:55] gah. Now I have a conflict in a plain replay. This means I made a mistake, I think [09:00] oh well, it's getting more and more automated. I think I'll start again it will be faster now. [09:01] quicksilver: you should mail the list or file a bug against bzr-rewrite, we definitely needs that feature [09:02] vila: maxb thought it might be possible with his branch of rewrite but I couldn't make it work. [09:02] vila: this could easily be my fault :) [09:03] quicksilver: *how* you end up make it work is the interesting part :) [09:03] I'm sure maxb will be interested too :) [09:06] * bialix hates such lame posts: http://community.livejournal.com/shlomif_tech/41922.html grr [09:12] vila: I will mail the list once I've got it all sorted. This is something of a crisis right now though. [09:13] quicksilver: Sure, I understand that === timchen1` is now known as nasloc__ [09:40] quicksilver, I think bzr-rewrite doesn't support what you need yet [09:40] 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:41] you can also use bzr fast-export/fast-import [09:41] they have the ability to filter out files [10:18] vila: hmm. No. I think my method is unsound after all. [10:19] :-/ [10:19] vila: when I do "bzr revert ." after the merge that reverts the added files [10:19] then when I readd them manually [10:19] they are flagged as coming in in *that* revision [10:19] rather than coming in in the revision they came in [10:19] which means they conflict on the next merge. [10:19] because bzr thinks they're different files. [10:20] I think really I want to only revert the conflicted files. [10:20] or, just bzr cat the conflicted files from the right revision. [10:20] hmm, yes, you should preserve the file-ids [10:21] is there a way to instruct a merge always to give priority to OTHER? [10:21] if you have only text conflicts then bzr cat -rnnn FILE ; bzr resolve FILE, should to it [10:22] bzr cat -rnnn FILE > FILE, you mean [10:22] but yes [10:22] quicksilver: There is a merge proposal about that for tree shape conflicts: https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785 [10:25] but that doesn't address text conflicts where more cases are needed [10:28] * quicksilver nods [10:29] quicksilver: you shouldn't generally do 'revert .' - because that *keeps* the record of the merge [10:31] lifeless: but that's exactly why I'm doing it [10:31] lifeless: I need to keep the record of the merge [10:31] but I don't want to do the hard work to resolve the conflicts again [10:31] so I want ot manuallly re-apply the previous conflict resolution. [10:31] * rml waves at quicksilver [10:35] 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:38] bzr pull --overwrite -r$MERGED ; bzr uncommit ; bzr shelve --all -m $MERGED [10:39] I think you can prepare the changes with that and then apply them after bzr revert . [10:40] bzr resolve --auto should then get rid of the text conflicts [10:40] vila: I have a different approach, which is maybe equivalent. [10:41] vila: suppose X.Y.Z is the revision which merges $MERGEID (and possibly fixes some conflicts or adds some more code) [10:41] vila: first bzr merge -R"revid:$MERGEID" [10:41] vila: then resolve all conflicts in favour of $MERGEID [10:41] vila: now, bzr merge -rX.Y.Z [10:41] vila: and that applies the new changes but it "notices" the $MERGEID is already merged and so that's OK. [10:41] vila: seemed to work just now. [10:42] cool, you'll get X.Y.Z as an additional parent though [10:42] but that may be better to show where you add to tweak your history [10:43] yeah, I don't really care about the extra parent [10:43] quicksilver: on the other hand if your merged branches are not poisoned why not just merged them as a whole ? [10:43] the general soundness is more important ) [10:44] vila: because of the conflicts? [10:45] 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:46] 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] s/knwo/know/ [10:47] ah bother, it didn't work with file add/rename conflicts [10:47] * quicksilver backtracks and thinks again [10:55] quicksilver: https://code.edge.launchpad.net/~vila/bzr/conflict-manager/+merge/16785 *implement* --take-theirs for add/rename conflicts ! [10:58] yes, I saw it. [10:58] "bzr merge -rX.Y.Z" is a bad idea. [10:59] it brings the poison back in. [10:59] ha, so the poison is in the other branches too then [11:02] no, X.Y.Z isn't the "other" branch [11:02] X.Y.Z was the bad branch anyway [11:03] how about 'merge -cX.Y.Z' then ? [11:06] oh, I didn't know about that one [11:07] what does -c do? the help page isn't very detailed :) [11:08] I'm unsure about it in your particular case :) It's supposed to bring only the changes in the specified revision [11:12] vila: bzr merge -cX.Y.Z gives bzr: ERROR: exceptions.AssertionError: Unknown kind 'relocated' [11:12] * vila bangs head on desktop [11:14] 2.0.1 right ? [11:14] 2.0.3 actually [11:14] upgraded yesterday whilst tearing hair out [11:15] 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:16] I'm 60% sure some bugs has been fixed in at least bzr.dev and may be bzr-2.1betaxx [11:17] but anyway, did you try the pull/uncommit/shelve trick ? [11:18] 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:21] vila: No. I think I'll try that next. [11:24] 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] vila: "wt" ? [11:24] working tree [11:25] * quicksilver nods [11:26] but pull --overwrite complete nukes my branch history? [11:29] nukes is a bit strong :) It makes your branch history the same as the one you're pulling from [11:29] and also updates the wt [11:33] vila: but I don't want to lose the branch history, do I? [11:34] or are you suggesting a use an auxiliary working tree and merge between [11:34] yup, when in doubt, always use a scratch monkey [11:34] vila: in particular, a bzr pull --overwrite will pull the poison back in. [11:34] yes, but it shouldn't pollute the shelved changes [11:35] when all your changes are ready, you can then, bzr pull --overwrite -r ../ and start from there [11:37] pull --overwrite -rrevno, gives you a branch and a working tree exactly as they were after the commit that created revno [11:37] something in the help page for shelve implies that it only applies to text changes though [11:37] so it won't fix my rename / binary problems? [11:38] if you uncommit/shelve, you should get unpoisoned changes from that [11:39] file a bug about that, shelve in bzr -core was rewritten from scratch to address shel from bzrtools relying on patch [11:39] if you get the wrong impression there, the doc should be fixed [11:40] Right. [11:40] So, I need one shelf per merge? [11:40] uncommit each merge point to a shelf [11:41] then pull a clean revision [11:41] and unshelve one merge at a time [11:41] well, (bzr merge ...; bzr revert.) to set the parent [11:41] and then unshelve the shelved version of the merge changeset on top [11:42] that's the idea [11:42] do shelves show up as a single change [11:42] or do they look like a merge? [11:43] think of shelves as you think about patches [11:44] you add or subtract them from a working tree, no merges or commits are involved [11:44] so I still want to replay the non-contentious revisions [11:44] if I want to keep as much of the history as possible [11:45] 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:46] so while you can get back the changes from the poisoned branches, you can't get their full history [11:48] yup [11:48]