| jelmer | hey poolie, fullermd | 00:01 |
|---|---|---|
| j1mc | hi - is there a bzr equivalent to 'git pull --rebase'? | 00:02 |
| LeoNerd | Possibly bzr rebase ? | 00:03 |
| LeoNerd | Though not knowing quite what that git pull --rebase does I'm not sure | 00:03 |
| j1mc | git pull --rebase allows you to update your branch with the current commits before you push your own commits | 00:04 |
| j1mc | LeoNerd: unfortunately, there doesn't appear to be a bzr rebase command | 00:04 |
| LeoNerd | Well, the usual way to do that in bzr would be to merge trunk into your branch first | 00:04 |
| poolie | j1mc: the equivalent is 'bzr rewrite' | 00:04 |
| LeoNerd | You -can- rebase, but that's somewhat rude as it rewrites history | 00:04 |
| poolie | from the bzr-rewrite plugin | 00:04 |
| poolie | i don't know if there is a specific one-shot command to do that | 00:04 |
| LeoNerd | It's generally much nicer to merge from the trunk into the branch, so that branch merges back into the trunk afterwards | 00:05 |
| LeoNerd | It doesn't involve any history-rewriting that way | 00:05 |
| LeoNerd | But still, if you want rebase, you'll find it in the bzr-rewrite plugin | 00:05 |
| jelmer | j1mc: "bzr rebase" does the same thing as "git pull --rebase" | 00:05 |
| jelmer | as LeoNerd and poolie point out, that command requires the bzr-rewrite plugin | 00:05 |
| j1mc | thanks for your help, all. i will give the bzr-rewrite plugin a try. | 00:07 |
| maxb | jelmer: Hi. I have been bitten by the broken not-quite-dpushed commits in dulwich again. | 00:08 |
| maxb | I would like to suggest deleting lp:~dulwich/dulwich/trunk from existence so that they cannot propagate further | 00:08 |
| maxb | I am currently wondering if I should manually recommit the recent history of the dulwich bzr-ppa branches for hardy/jaunty/karmic to excise them | 00:09 |
| poolie | hi maxb | 00:10 |
| maxb | hello | 00:10 |
| * maxb hugs the lp api and lpshell | 00:15 | |
| maxb | having just been able to do a loop over all ~bzr recipes calling r.distroseries.remove(karmic) on them all | 00:16 |
| maxb | hm | 00:18 |
| maxb | but it doesn't seem to have taken effect | 00:18 |
| * maxb is less impressed now | 00:20 | |
| jelmer | poolie: Thanks for also looking at Vincent's config patches | 00:21 |
| jelmer | maxb: The same commits or different ones? | 00:21 |
| poolie | that's ok | 00:21 |
| poolie | do you want to talk about it? | 00:21 |
| poolie | i'm wondering if we should in fact do per-file configuration on the way i discussed in the overall mp | 00:21 |
| jelmer | maxb: please note that that branch is just a mirror of another one | 00:21 |
| maxb | jelmer: same ones causing problems in new scenarios | 00:21 |
| jelmer | maxb: So it's all old stuff? | 00:21 |
| maxb | jelmer: OK, let's delete all branches in the world with the dodgy commits :-) | 00:22 |
| knighthawk | I'm thinking a work around may be to just to add a working tree to A | 00:22 |
| knighthawk | but yeah fullermd that's my situation. | 00:22 |
| maxb | jelmer: 2011-01-14 is the most recent problem revision | 00:23 |
| jelmer | maxb: if it's all old commits I'm happy to delete and repush those branches, if there are new commits involved as well we should probably investigate further | 00:23 |
| jelmer | maxb: That's old enough for me :) | 00:23 |
| jelmer | poolie: I think the idea of mixing config and rules is interesting | 00:24 |
| poolie | if they're going to stay separate, i'd like to have a clear idea of why they're separate | 00:24 |
| poolie | beyond just 'rules are per-file' | 00:24 |
| maxb | I'm currently trying to decide whether it would be quicker to manually recommit the history for the bzr-ppa branches, vs. hack up reconcile with "where you see this text parent, change it to that one" logic | 00:24 |
| maxb | knighthawk: If you'd followed the exact sequence of commands you mentioned earlier, I don't see how you could have diverged branches | 00:26 |
| jelmer | poolie: My impression of it is that rules are things that could potentially apply to everybody accessing a particular branch | 00:26 |
| jelmer | whereas config is specific to a specific machine or user | 00:26 |
| jelmer | That's how I think of them at least, not sure if it necessarily makes sense. | 00:26 |
| maxb | knighthawk: Perhaps a pastebin of your console session would explain things best | 00:26 |
| knighthawk | maxb I did do a commit of new code in my branch before trying to do the pull from svn | 00:28 |
| poolie | that is true | 00:28 |
| jelmer | poolie: I realize that doesn't entirely match our current use, as we don't currently allow you to declare "doc/en/release-notes/*.txt" as changelog files that should be processed with the custom changelog merger | 00:28 |
| poolie | but perhaps they should just be different layers that stack together | 00:28 |
| maxb | knighthawk: In that case I think you misunderstand the nature of "pull" | 00:28 |
| poolie | perhaps it's too confusing if some are trusted and some not | 00:28 |
| maxb | knighthawk: "pull" is for making a local branch be identical to some remote one. Once you've committed stuff locally, that's no longer possible. You want to merge, I guess, instead. | 00:29 |
| knighthawk | maxb quite possible, I went ahead and created a working tree in 'A' now I'm going to try to merge 'A' and 'B' | 00:29 |
| jelmer | poolie: yeah, trust is indeed an interesting thing in this too | 00:29 |
| knighthawk | maxb I guess what I want to do is like a update of the local branch to the central repo before I try to commit my changes back into svn. | 00:30 |
| maxb | knighthawk: Right. "bzr merge svn+ssh://my.svn.server/svn/repository/project/trunk" for example | 00:31 |
| knighthawk | maxb can I just merge to a svn repo? (I don't know why but I assumed I couldln't do that) | 00:32 |
| maxb | No, because you can only merge into a working copy | 00:32 |
| knighthawk | ah. okay I just merged my changed from B into A so now I want to merge from the svn repo into A then do a commit (I think) | 00:33 |
| jelmer | poolie: food for thought :) | 00:37 |
| * jelmer gets some sleep | 00:37 | |
| poolie | :) sleep well | 00:37 |
| spiv | jelmer: I'd like to update news_merge to use rules, actually | 00:52 |
| poolie | hi there spiv | 00:53 |
| poolie | so spiv, what do you think of unifying them? | 00:54 |
| stewart | help help! "permission denied" using 'bzr switch' ? http://paste.drizzle.org/show/481/ | 00:54 |
| poolie | hi stewart | 00:54 |
| stewart | poolie, hi! | 00:54 |
| poolie | the eperm is a distraction just meaning you don't have a /var/crash or something | 00:55 |
| poolie | looks like https://bugs.launchpad.net/bzr/+bug/623152 | 00:55 |
| ubot5 | Ubuntu bug 623152 in Bazaar "ValueError: need more than 1 value to unpack in _last_revision_info" [Undecided,Expired] | 00:56 |
| stewart | huh... | 00:56 |
| poolie | > That traceback suggests the .bzr/branch/last-revision file is corrupt, probably blank. What does it contain? | 00:56 |
| stewart | poolie, it's 0 bytes long | 00:56 |
| stewart | poolie, so probably something that wasn't written out during one of the "damn laptop hung... probably due to intel wireless drivers" events last week | 00:57 |
| poolie | sorry, yeah | 00:57 |
| poolie | we should almost just fsync everything, except that would make things pretty slow for people whose machine aren't crashing | 00:57 |
| poolie | can you see if 'bzr reset-dirstate' fixes it? | 00:57 |
| stewart | poolie, unknown command... some plugin i'm missing? | 00:58 |
| poolie | ah it might only be in bzr 2.4 | 00:58 |
| stewart | ahh.. .and i'm 2.3.1 | 00:59 |
| poolie | do you have a lot of uncommitted work? | 00:59 |
| poolie | it might be faster to just make a new tree | 00:59 |
| stewart | poolie, no. | 00:59 |
| stewart | poolie, wiping away the checkout is fine. | 00:59 |
| poolie | i will update that bug to say there should be an easier way to recover | 00:59 |
| teratorn | does the windows installer support bzr+ssh urls out of the box? | 00:59 |
| teratorn | tortoisebzr? | 00:59 |
| poolie | teratorn: i think so yes | 00:59 |
| stewart | poolie, i have no problems with it fsyncing such things. nooo problem with that at all :) | 01:00 |
| poolie | maybe at least an option would be good | 01:00 |
| poolie | in fact an option that just globally fsync'd on close could be good | 01:00 |
| spiv | poolie: my understanding of the purpose of rules is the same as jelmer's | 01:00 |
| poolie | at least as 'fool me twice' prevention | 01:00 |
| poolie | that's my understanding too | 01:01 |
| spiv | well, versioned-in-tree config about that tree | 01:01 |
| poolie | however, i'm not sure we need a separate and somewhat parallel api to get it | 01:01 |
| spiv | It definitely has a lot in common with other kinds of config | 01:01 |
| spiv | We have perhaps slightly different concerns about versioning the format of rules vs configs, but in terms of API it sounds reasonable to have as much commonality as possible. | 01:03 |
| stewart | poolie, attempted new lightweight checkout for my working dir... http://paste.drizzle.org/show/482/ | 01:03 |
| spiv | There is also a difference that in practice rules are used for per-file stuff, or at least 'per-thing in tree as matched by globs', and mostly other configs don't do that. | 01:04 |
| poolie | stewart ah the problem is actually in the branch not the tree | 01:04 |
| stewart | poolie, oh yeah, last-revision is empty there too | 01:05 |
| poolie | if that's your trunk, delete the branch directory | 01:05 |
| poolie | and pull from the server again | 01:05 |
| stewart | poolie, i have a mirror of it on lp... | 01:05 |
| stewart | (of that branch) | 01:05 |
| poolie | it's actually lost its idea of what the tip is | 01:05 |
| poolie | you don't need to delete the repo, only the branch | 01:05 |
| poolie | so it should be quite fast to fetch | 01:05 |
| stewart | yep. branch going away. | 01:05 |
| stewart | poolie, FYI it left the lightweight checkout dir in an odd state...just wiping it and trying again | 01:07 |
| stewart | poolie, question, is there any efficiency in packing binary data in the repo apart from simple compression? e.g. if we had X number of 10MB files that were *mostly* the same, would we get anything better than X*10MB disk usage? | 01:09 |
| poolie | yes you would | 01:10 |
| stewart | poolie, I'm wanting to have various InnoDB data files in the tree for backwards compatibility testing. | 01:10 |
| stewart | without having people whine at me that the repo is now 400MB :) | 01:10 |
| poolie | one caveat is that compression only hppens within pack files | 01:10 |
| poolie | so if you successively commit 10 additions of those files, you will have 10 pack files each ~10MB | 01:10 |
| stewart | poolie, i can deal with that. (i gather a repack would reclaim a lot of space) | 01:11 |
| poolie | however, the compression on the 10th commit should shrink them all into one pack somewhat less than 100MB | 01:11 |
| poolie | right | 01:11 |
| stewart | 10x10MB files with only about 1MB difference should be closer to 20MB on disk than 100MB | 01:11 |
| lifeless | stewart: yes, thats right. Do an experiment :) | 01:11 |
| stewart | nice :) | 01:11 |
| stewart | we were discussing if we would gzip these in tree or not, rather convinced we should just store them in there now. | 01:12 |
| stewart | it turns out some people care not to have to sql dump and restore their database :) | 01:12 |
| poolie | bzr will be able to compress them better if they're not individuall gzipped | 01:15 |
| poolie | which will hide any similarities | 01:15 |
| lifeless | lp stores a SQL dump of some MBs of data in tree | 01:16 |
| lifeless | it compresses pretty well | 01:16 |
| lifeless | its a tad fugly, but if you need it you need it. | 01:16 |
| lifeless | I would suggest having it in a dedicated tree perhaps | 01:17 |
| poolie | that sounds like a good idea | 01:19 |
| === wallyworld___ is now known as wallyworld | ||
| poolie | <jam> This fixes a bug that Mark Shuttleworth pointed out to me (bug #765881) | 01:43 |
| poolie | nice | 01:43 |
| ubot5 | Launchpad bug 765881 in Bazaar "newly added files always trigger IN_MEMORY_MODIFIED" [High,In progress] https://launchpad.net/bugs/765881 | 01:43 |
| * spiv gives his wireless router a kick | 02:06 | |
| poolie | stewart also https://bugs.launchpad.net/bzr/+bug/766735 | 02:36 |
| ubot5 | Ubuntu bug 766735 in Bazaar "people get confused by apport messages" [Medium,Confirmed] | 02:36 |
| poolie | spiv do you have any ideas about https://bugs.launchpad.net/bzr/+bug/721163 | 02:36 |
| ubot5 | Ubuntu bug 721163 in Bazaar "bzr crashed with ErrorFromSmartServer: ('error', 'bytes must be a string')" [Undecided,New] | 02:36 |
| spiv | poolie: hmm, no | 02:43 |
| spiv | poolie: I think we need the server-side log | 02:44 |
| spiv | I can't think of any likely causes, and I don't think any hooks are triggered by insert_stream so it's unlikely to be a buggy plugin | 02:44 |
| poolie | so can you say so? | 03:06 |
| spiv | Sure. | 03:36 |
| johnf | Is it possible to find all the dangling revisions in a repository created by uncommit? | 06:16 |
| lifeless | bzr heads --all | 06:18 |
| KombuchaKip | Is there any way to setup a post commit hook for bzr to send an email when using it with Launchpad? | 06:19 |
| johnf | lifeless: cheers | 06:20 |
| lifeless | KombuchaKip: if your branch is on launchpad you can just click on subscribe in the UI | 06:20 |
| poolie | KombuchaKip: the people interested in the branch can just subscribe to it in lp | 06:20 |
| poolie | or you can use bzr-email | 06:20 |
| poolie | o/ johnf | 06:20 |
| lifeless | KombuchaKip: if you want the mail sent to a list, you can subscribe a team with a contact address of the mailing list (or the team itself if its a launchpad hosted list) and LP will mail that directly. | 06:20 |
| KombuchaKip | poolie: I'd like to use bzr-email, but not sure if you can use that with launchpad since you won't have access to server? | 06:21 |
| KombuchaKip | lifeless: Thanks. I think that's what I will do. | 06:21 |
| poolie | it runs on the client | 06:21 |
| poolie | sending it from lp seems easier | 06:21 |
| KombuchaKip | poolie: Thanks. | 06:24 |
| KombuchaKip | This is always a friendly and helpful channel. | 06:39 |
| poolie | thanks | 07:07 |
| maxb | poolie: Thanks for the pointer to deryck's bzr issue. As it turned out, it was actually a launchpad-specific bzr plugin that was at fault, so no problem for us on the #bzr side of things :-) | 07:09 |
| poolie | o/ bialix | 07:11 |
| poolie | hooray | 07:12 |
| poolie | spiv, jelmer, jam, hi? | 08:58 |
| jam | hi poolie | 08:58 |
| jam | "Are you ready to Muuuummblllllllllleee" ? | 08:58 |
| jam | (said w/ a WWE announcer voice) | 08:59 |
| poolie | :) :) | 08:59 |
| poolie | be back in a sce | 09:00 |
| * jelmer is still setting up | 09:08 | |
| spiv | poolie, jelmer, jam: damn, forgot what day it was | 09:21 |
| poolie | np, want to join us now? | 09:22 |
| spiv | Ok | 09:22 |
| jam | spiv: pack retry attacked back | 09:26 |
| jam | poolie: this one? https://wiki.canonical.com/Bazaar/Plan/2011 | 09:34 |
| jam | spiv: yeah, we don't hear you | 10:02 |
| poolie | jam re bug 746237 i was just going to check if there's a new bug | 10:33 |
| ubot5 | Launchpad bug 746237 in Bazaar "Documentation markup bugs" [High,In progress] https://launchpad.net/bugs/746237 | 10:33 |
| jam | poolie: sure | 10:34 |
| jam | I don't think there is a new one | 10:34 |
| poolie | i'll do a pass over all of ~mbp inprogress today or tomorrow | 10:35 |
| jam | poolie: what is our current 'bug fix' policy | 10:40 |
| jam | it should always target 2.3? | 10:40 |
| jam | or 2.2? | 10:40 |
| jam | or ...? | 10:40 |
| jam | I have a fairly trivial fix for bug #760152 which I can backport as far as we want | 10:40 |
| ubot5 | Launchpad bug 760152 in Bazaar "bzr merge --pull --preview BRANCH does not always honor the --preview option" [High,In progress] https://launchpad.net/bugs/760152 | 10:40 |
| jam | the main issue is just how much effort do we want to spend merging-up | 10:40 |
| poolie | serious bugs with safe fixes in 2.1 | 10:41 |
| poolie | bugs worth fixing with safe fixes in 2.3 | 10:41 |
| poolie | i guess | 10:41 |
| poolie | 2.0 basically dead except by request | 10:41 |
| poolie | iow i think the safety bar is equally high | 10:42 |
| poolie | but, merging into 2.1 is a bit more work, so we should only do it when we specifically think it'll please someone | 10:42 |
| jam | poolie: sure. I guess my issue here is how to handle the merge-up and the RELEASE NOTES | 10:42 |
| poolie | on lts | 10:42 |
| poolie | right | 10:42 |
| jam | Yay, closing a 4-digit bug | 10:54 |
| jam | bug #5135 | 10:54 |
| jam | I tested it, and it works fine here | 10:55 |
| ubot5 | Launchpad bug 5135 in Bazaar "bzr diff -r X..Y path/to/branch fails if path/to/branch is a symbolic link" [Medium,Fix released] https://launchpad.net/bugs/5135 | 10:55 |
| jam | ubot5: you're getting slow, man | 10:55 |
| ubot5 | Error: I am only a bot, please don't think I'm intelligent :) | 10:55 |
| poolie | way to go! | 10:57 |
| poolie | if there were badges, you would get at least a silver one | 10:57 |
| jam | poolie: well, closed because it has already been fixed. But still feels good. | 11:05 |
| jelmer | :) | 11:14 |
| poolie | maybe we should just make a web page with badges if we can't do it automaticaly | 11:21 |
| spiv | poolie: or a greasemonkey script? | 11:33 |
| jelmer | spiv: if you're still around and interested, we're having a udd meeting #ubuntu-meeting | 12:02 |
| jelmer | *in | 12:03 |
| poolie | jam: hi? | 12:03 |
| === mrevell is now known as mrevell-lunch | ||
| mrevell-lunch | Morning/nick mrevell | 13:50 |
| mrevell-lunch | sorry | 13:51 |
| === mrevell-lunch is now known as mrevell | ||
| mrevell | :) | 13:51 |
| jkakar | Hi ntoll! :) | 14:23 |
| ntoll | hi jkakar | 14:23 |
| ntoll | fancy seeing you in here ;-) | 14:23 |
| jkakar | ntoll and I have discovered something funky in our branches... | 14:23 |
| jkakar | We have trunk, staging and production branches, each of which is meant to be older than the last (and we're careful with merges). | 14:23 |
| jkakar | We have a situation where production doesn't contain content in a file that, after carefully analyzing the logs, we think should be there. | 14:24 |
| jkakar | So I ran 'bzr check' and got this: | 14:24 |
| jkakar | 3838 revisions | 14:24 |
| jkakar | 1360 file-ids | 14:24 |
| jkakar | 3 inconsistent parents | 14:24 |
| jkakar | I'm wondering what '3 inconsistent parents' means...? | 14:24 |
| jkakar | Could it be that some flummox in merging could have removed the content we expect... | 14:24 |
| jkakar | For example, I seem to remember reverting a revision could produce strange results when you merged it back...? | 14:25 |
| jkakar | abentley: ^^ Any ideas? | 14:26 |
| abentley | jkakar: No, inconsistent parents are mostly harmless. They are usually due to ghost revisions or bzr bugs. | 14:39 |
| jkakar | abentley: Okay, thanks. :) | 14:39 |
| jkakar | abentley: I guess bzr bugs are mostly harmless? ;b | 14:40 |
| jkakar | abentley: Anyway, I think we figured out the issue is an EPEBKAC error. :) | 14:40 |
| abentley | Ah, okay. | 14:40 |
| jkakar | abentley: Thanks for your feedback, much appreciated... these kinds of "WTF?" moments are always a bit scary. :) | 14:40 |
| abentley | jkakar: no problem. | 14:42 |
| fullermd | I think 'reconcile' will often fix inconsistent parents. | 14:43 |
| jkakar | fullermd: Yeah, I was wondering about it... but 'bzr help reconcile' says, "You should only need to run this command if 'bzr check' or a bzr developer advises you to run it." | 14:44 |
| jkakar | fullermd: Neither of those things happened so I didn't run it. | 14:44 |
| maxb | What exactly is an "inconsistent parent"? Is this described anywhere? | 14:47 |
| jkakar | maxb: I was wondering the same... I couldn't easily find anything about it. | 14:47 |
| maxb | I gather it's something to do with consistency between the overall revision graph and the ancestry attributed to individual files | 14:49 |
| jkakar | maxb: I gathered the same, yeah. | 14:50 |
| diwic | What do I do about this: "bzr bd" gives error "Unable to determine the previous upload for --package-merge"? | 15:39 |
| james_w | diwic, "bzr branch lp:bzr-builddeb /tmp/builddeb; BZR_PLUGINS_AT=builddeb@/tmp/builddeb bzr bd" | 15:43 |
| diwic | james_w, iow this is a known bug that is fixed in trunk? | 15:44 |
| james_w | diwic, indeed | 15:44 |
| diwic | thanks! | 15:45 |
| === diwic is now known as diwic_afk | ||
| knighthawk | I've seen a few places that mention rebase. perhaps as a solution to my problem committing to svn. But when I try to run 'bzr rebase' or 'bzr help rebase' it says it doesn't exist. am I doing something wrong? | 17:56 |
| === abentley is now known as abentley-lunch | ||
| niemeyer | Hey there | 17:57 |
| knighthawk | looks like I'm running bzr 2.1.1-4 | 17:57 |
| jelmer | knighthawk: rebase is in the bzr-rewrite plugin | 17:57 |
| niemeyer | Getting some issues with bzr-fastimport related to an AttributeError on _find_ancestors | 17:57 |
| knighthawk | jelmer thanks | 17:57 |
| niemeyer | On natty, specifically | 17:57 |
| niemeyer | Is that a known issue? | 17:58 |
| jelmer | hi Gustavo | 17:58 |
| jelmer | niemeyer: it sounds vaguely familiar - can you pastebin the backtrace? | 17:58 |
| niemeyer | jelmer: Hi! | 17:58 |
| niemeyer | Sure | 17:58 |
| niemeyer | jelmer: http://pastebin.ubuntu.com/596621/ | 17:58 |
| jelmer | niemeyer: thanks | 18:01 |
| jelmer | niemeyer: it's indeed something I've seen before | 18:01 |
| jelmer | https://bugs.launchpad.net/bzr-fastimport/+bug/541626 | 18:03 |
| ubot5 | Ubuntu bug 541626 in Bazaar "'BTreeBuilder' object has no attribute '_find_ancestors'" [High,Confirmed] | 18:03 |
| jelmer | I'm not too familiar with the index code, perhaps John can comment on it tomorrow. | 18:05 |
| jelmer | it looks shallow | 18:05 |
| niemeyer | jelmer: Cool, thanks | 18:07 |
| mgz | jelmer, did you have a branch that had some code doing isinstance(revision_id, basestring) up for review? I now can't find the mp and think I may have imagined it. | 18:40 |
| jelmer | mgz: perhaps the branch that forbade using None as alias for "null:" in Branch.set_last_revision_info() ? | 18:41 |
| mgz | maybe. do you have a link? I meant to ask whether said variable should actually be bytes or unicode. | 18:42 |
| jelmer | mgz: that was inspired by some other code in bzrlib.revision that did the same thing IIRC | 18:42 |
| mgz | I thought it was one of the ones removing the inventory stuff and switching a param to be a tree or something instead | 18:43 |
| jelmer | tjatlp:~jelmer/bzr/testament-tree ? | 18:43 |
| jelmer | that's lp:~jelmer/bzr/testament-tree ? | 18:43 |
| jelmer | bzrlib.revision.is_reserved_id() checks against basestring | 18:44 |
| jelmer | mgz: it happens in more places, e.g. Repository._iter_revisions | 18:46 |
| mgz | must have confused two different diffs. I've not been keeping up with for coding. :) | 18:46 |
| === abentley-lunch is now known as abentley | ||
| ironmagma | does bzr require you to download the whole repository history, like git/hg do? | 21:44 |
| Odd_Bloke | ironmagma: You can use lightweight checkouts, which do not. | 21:45 |
| knighthawk | svn users aren't too happy with me right now, somehow I blew away the svn history for a few days with my push. is this because in my ~/.bazaar/suvbersion.conf I added append_revision_only = False? | 22:06 |
| lifeless | push shouldn't even be destructive, unless you used --overwrite | 22:07 |
| lifeless | s/even/ever/ | 22:07 |
| knighthawk | did *not* use overwrite | 22:07 |
| lifeless | jelmer: ^ around ? | 22:07 |
| knighthawk | I did a bzr merge to merge my working tree to what was supposed to be the latest version of the svn repo (only it seems it wasn't) then I commited my changes and tried to do a push that didn't work until I added append_revision_only = False but then it seems I blew up some stuff. I've since installed bzr-rewrite and now I'm trying rebase instead of append_revision_only = False. but since I'm not *sure* that's what created the problem I'm not sure if I'm | 22:10 |
| knighthawk | going to do it again. | 22:10 |
| lifeless | yeah, I can understand that | 22:12 |
| lifeless | sadly, I've only used bzr svn a very few times myself, so I don't really have a clue about whats up there | 22:12 |
| jelmer | re | 22:17 |
| jelmer | hi lifeless, knighthawk | 22:18 |
| knighthawk | hey jelmer | 22:19 |
| jelmer | knighthawk: yes, if you set "append_revisions_only = False" that means bzr-svn will push even if that removes existing revisions from the mainline (the revisions are still in the repository, just not in the mainline of the branch) | 22:19 |
| jelmer | knighthawk: The default of append_revisions_only=True is intended to prevent you from shooting yourself in the foot | 22:20 |
| knighthawk | jelmer, okay it *sounds* like now that I have bzr-rewrite working I can use rebase and don't need append_revision_only=False anymore (I think) | 22:21 |
| jelmer | knighthawk: you can restore the old mainline using either "svn cp -r ..." or "bzr push --overwrite ..." | 22:21 |
| jelmer | knighthawk: right, rebase will preserve the upstream branch mainline | 22:22 |
| knighthawk | jelmer sorry I'm not sure what is meant by mainline is that the trunk? | 22:22 |
| jelmer | knighthawk: mainline are basically the revisions shown by "bzr log -n1" | 22:22 |
| jelmer | knighthawk: non-mainline revisions will be shown too if you use "bzr log -n0" | 22:22 |
| knighthawk | thanks jelmer that clears up a lot. but now did I just destroy my changes of restoring the mainline by running rebase? | 22:31 |
| jelmer | knighthawk: it depends on what exactly you rebased | 22:32 |
| === foocraft is now known as [1984] | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!