| === AnMaster_ is now known as AnMaster | ||
| sverrej | I get this error when trying to checkout a svn branch with bzr branch svn+http://foo/trunk : | 11:18 |
|---|---|---|
| sverrej | bzr: ERROR: bzrlib.errors.KnitCorrupt: Knit <bzrlib.knit._KnitAccess object at 0x8a639ac> corrupt: incorrect number of lines 73 != 59 for version {svn-v3-trunk1:f4d88352-fc0f-0410-91c6-821c4d51a43f:my.opera.com%2Ftrunk:329} | 11:19 |
| AfC | sverrej: as ever in Open Source land, it would help your cause if you would tell people what version of Bazaar you were using, what OS distro, etc. | 11:19 |
| sverrej | I read about someone having the same problem, where the solution was to do incremental pulls, because bzr-svn uses too much memory, but that did't help. | 11:20 |
| sverrej | AfC: Sure :) | 11:20 |
| sverrej | Ubuntu Gutsy, Bazaar 0.92.0.candidate.1 and bzr-svn-0.4.4 | 11:21 |
| sverrej | Should be latest version | 11:21 |
| sverrej | I have a backtrace too. I'll post it somewhere | 11:22 |
| sverrej | http://pastebin.com/m51c4dba3 | 11:24 |
| === bigdo1 is now known as bigdog_ | ||
| lifeless | moin | 13:32 |
| mwh | morning lifeless | 13:44 |
| sverrej | good morning | 13:48 |
| lifeless | bbiab | 13:57 |
| zerok | hi :-) short question: when you push a changeset to a remote repository, is there some hook that could be exploited for example for automatically updating the working tree there? | 14:01 |
| beuno | zerok, there is a plugin calles "push-and-update", that might be what you're looking for | 14:19 |
| beuno | it runs locally, and updates via SSH, so make sure you have SSH access | 14:19 |
| beuno | I'm not sure you can add a hook on the server side without having smart server running as the "push" command is done entirely locally, but the push-and-update plugin works fine if you have ssh access | 14:20 |
| zerok | beuno, thanks :-) | 14:20 |
| beuno | zerok, :D | 14:20 |
| pbor | can I use bzr-svn to do a smarter merge of two svn branches? | 14:46 |
| pbor | lemme explain... I have a svn repo with a branch "foo" and trunk that have diverged a bit | 14:47 |
| pbor | now I want to merge foo into trunk | 14:47 |
| pbor | and I was wondering if using bzr-svn could help | 14:47 |
| jelmer | pbor: Yeah, it should at least be smarter than "svn merge" | 14:48 |
| pbor | jelmer: but if I use bzr to checkout svn/branch/foo and svn/trunk, is bzr smart enough to understand they are branches of the same repo? | 14:49 |
| jelmer | pbor: Yes, it will recognize if they have common ancestry | 14:50 |
| pbor | jelmer: cool... I guess my best bet is get bzr latest and bzr-svn latest, right? | 14:53 |
| jelmer | yep | 14:53 |
| jdong | does Launchpad currently support dirstate-tags format branches? | 16:04 |
| Peng | Can you try it and see? | 16:04 |
| jdong | well I tried running a bzr upgrade over sftp:// and it sat there spinning for 15 minutes | 16:05 |
| jdong | on a fairly small sized repository | 16:05 |
| jdong | I figured someone here might directly know, without me risking creating junk on LP | 16:05 |
| lifeless | jdong: yes it does | 16:09 |
| lifeless | jdong: generally launchpad supports anything supported by the release-1 of bzr | 16:10 |
| jdong | lifeless: fantastic; how do I convert an existing branch to dirstate-tags? | 16:11 |
| jdong | was I just impatien with bzr upgrade? | 16:12 |
| === Ng_ is now known as Ng | ||
| lifeless | jdong: yes, I think so :) | 16:57 |
| lifeless | jdong: it takes a backup for safety | 16:57 |
| MishaS | hi. can somebody recommend a doc about bzr merging? :) | 18:40 |
| beuno | MishaS, maybe this? http://doc.bazaar-vcs.org/bzr.0.92rc/en/user-guide/conflicts.html | 18:44 |
| * MishaS is checking the suggested doc | 18:48 | |
| MishaS | beuno, thanks, but it seems to address only part of my misunderstanding :) | 18:49 |
| beuno | MishaS, what are you looking for specifically? | 18:50 |
| MishaS | beuno, let's have i have 'trunk' | 18:54 |
| MishaS | beuno, and a lot of people (at least somebody beside me :)) is working on that | 18:55 |
| MishaS | beuno, now i started to work on a new feature: bzr branch trunk new-feature | 18:55 |
| MishaS | beuno, i did some changes to the branch and would like to catch up with trunk changes: bzr merge; <resolve conflicts if any>; bzr ci -m 'merged with upstream' | 18:56 |
| MishaS | beuno, now, for one week i do not touch my branch as other things were happening | 18:56 |
| MishaS | beuno, in one week i decided to catch up with changes again and my natural reaction is/was: bzr pull | 18:57 |
| === mw is now known as mw|food | ||
| === mw|food is now known as mw|lunch | ||
| MishaS | beuno, how it does not work. i need to again 'bzr merge' and then 'bzr ci' | 18:57 |
| beuno | MishaS, that's correct | 18:57 |
| MishaS | beuno, so i'm looking for a document that would clarify why it must be done like this :) | 18:58 |
| beuno | MishaS, you can also use the SVN-like model, and use checkouts | 18:58 |
| MishaS | beuno, sorry, i don't exactly follow :) | 18:59 |
| beuno | MishaS, http://bazaar-vcs.org/FAQ#head-73f0b8ea8515a0087ce8705fbaafc55c80a0a30e | 18:59 |
| dato | beuno: uuh, that wouldn't quite work, since he's working in a separate branch? | 18:59 |
| beuno | that might help | 18:59 |
| beuno | dato, right, he'd have to do bzr update on a frequent basis | 18:59 |
| MishaS | beuno, without having my changes committed? | 19:00 |
| beuno | MishaS, what about that workflow don't you understand? If the parent branch has changes, you have to merge them into yours | 19:00 |
| beuno | MishaS, you have to have your changes commited so conflicts can be resolved | 19:01 |
| MishaS | beuno, yes, but i did it once and then nothing was changed, why should i resolve non existing conflicts again? | 19:01 |
| beuno | MishaS, you don't have to resolve conflicts if there aren't any | 19:01 |
| beuno | if the merge was clean, you just have to commit the changes to your repository | 19:02 |
| beuno | or work on them, and then commit | 19:02 |
| beuno | conflicts are only for when bzr can't guess how to merge the changes | 19:02 |
| beuno | so you have to interveen | 19:02 |
| MishaS | beuno, i kinda _feel_ inconsistency... | 19:02 |
| MishaS | beuno, and cannot really explain it... :( | 19:03 |
| beuno | MishaS, that it's a bit hard for me to help :D | 19:03 |
| beuno | have you used other VCS before? | 19:03 |
| MishaS | beuno, probably the behaviour i expect is that after that merge new changes would be just on top of the last merge without additional effort | 19:03 |
| beuno | or rather, how would you want the workflow to work? | 19:03 |
| beuno | MishaS, ah, I understand | 19:04 |
| MishaS | beuno, i have :) and it was never like this :)) i just hope that bzr is closer to what i aniticipate... :) | 19:04 |
| * MishaS used cvs, visual source safe, p4, and now is jumping between svn/git/hg/bzr :) | 19:05 | |
| MishaS | (p4 was not for too long though) | 19:05 |
| beuno | MishaS, have you taken a look at: http://bazaar-vcs.org/Workflows | 19:05 |
| beuno | I'm not sure why merge can't just bring the commits into the revision history, one of the devs can probably answer that better then me | 19:06 |
| MishaS | beuno, yes, it was quite some ago though.... | 19:06 |
| MishaS | i would say that _some_ merges cannot be brought directly, but if they can, why not? | 19:07 |
| MishaS | and probably something like rebase would be more appriate for me.. | 19:08 |
| * beuno looks ar abentley, fullermd and jam-laptop for input | 19:09 | |
| dato | rebase *may* be what you want, *but* it doesn't fit the recommended bzr workflow | 19:10 |
| MishaS | (appropriate) | 19:10 |
| MishaS | dato: what do you mean "does not fit"? i believe if a feature is developed using 'rebase' than when it's merged to trunk it looks clean and nice, no? | 19:11 |
| lifeless | ~. | 19:11 |
| hstuart | MishaS, I think one of the ideas is to allow you to merge another developers changes without having to commit them to your branch, for looking at experimental features or what have you - at least that makes sense to me | 19:11 |
| * MishaS is now complete lost :) | 19:12 | |
| dato | MishaS: well, in eg. git you can do many things with rebase, like merging commits into only one, and in general making them "nice" | 19:12 |
| lifeless | MishaS: rebase sacrifices collaboration for prettiness | 19:12 |
| fullermd | Hm? What? Who called? The goldfish were in the blender when I got there, I swear. | 19:12 |
| dato | MishaS: in bzrland, though, people have normally nothing against merging branches with many small commits, including those "merge upstream" ones | 19:13 |
| beuno | and I also heheh | 19:13 |
| MishaS | ok. now, i think, i get it: bzr priorities are 'collaboration' and only then 'prettyness'. that actually helps to understand the things. really. | 19:14 |
| * fullermd doesn't quite understand the question... | 19:15 | |
| dato | fullermd: "why do merges which generate no conflicts require a commit" | 19:15 |
| lifeless | MishaS: there is a rebase plugin for bzr. | 19:15 |
| dato | fullermd: more or less | 19:15 |
| fullermd | Mmm. Well, in this case, merging trunk into your branch, you wouldn't want rebase; that would cause big honkin' ugliness when you merge back into trunk. | 19:16 |
| fullermd | Rebase is more for merging your branch back onto trunk, erasing all your intermediate steps. | 19:16 |
| MishaS | lifeless, thank you | 19:17 |
| * MishaS checks bzr web site for rebase plugin | 19:17 | |
| Peaker | fullermd: don't you want to merge in your branch, and try to only push to trunk? | 19:17 |
| Peaker | when you say rebase you make me think ClearCase | 19:17 |
| MishaS | fullermd, rebase will make my changes quite separate from trunk | 19:17 |
| fullermd | Well, that's a workflow question; neither answer is "right" per se, it depends on what you're trying to accomplish. | 19:18 |
| fullermd | I don't go in for push to trunk flows, since that could change trunk's LHS. | 19:18 |
| MishaS | fullermd, if i really have to 'merge with upstream' only when there are conflicts it'd still look 'clean' in the changelog, otherwise they do seem to make the changelog a bit too overloaded | 19:18 |
| Peaker | I think its probably easier to test the coherency of your work in your own branch where you usually do the work, so merges happen there, and when you push to trunk you know you are making it identical to your copy | 19:19 |
| Peaker | fullermd: LHS? | 19:19 |
| fullermd | Well, even if there are no conflicts, there still has to be a new revision, because you're making a state that doesn't already exist. | 19:19 |
| lifeless | Peaker: left-hand-side history | 19:19 |
| Peaker | lifeless: what does it mean? | 19:19 |
| fullermd | Some of the other DVCSen automatically commit if there are no conflicts (mtn and git I know do; not sure about hg). | 19:20 |
| lifeless | a merge merges two revisions X and Y to give Z. Z:[X,Y] | 19:20 |
| MishaS | fullermd, i see. | 19:20 |
| Peaker | lifeless: with common ancestor B, yeah | 19:20 |
| lifeless | the left hand history is what you get by following just X at every step | 19:20 |
| fullermd | bzr doesn't. I like that better; it means you can supply a more meaningful commit message. Also, just because there are no textual conflicts, doesn't mean there aren't any conceptual conflicts. | 19:20 |
| lifeless | Z.parent_ids[0] -> Z.parent_ids[0].parent_ids[0] etc | 19:20 |
| fullermd | e.g., somebody renamed a function that your code calls. Merge won't find any conflicts, since there aren't any textual clashes in your changes, but now you're trying to call a function that no longer exists. | 19:21 |
| lifeless | Peaker: a merge does not imply a common ancestor :) | 19:21 |
| Peaker | lifeless: how can a merge be without one? Revision 0 is always a common ancestor, isn't it? | 19:22 |
| Peaker | fullermd: so you want such a revision to be considered a merge? | 19:22 |
| lifeless | well, null: is a theorietical common ancestor, but if you have partial history for two branches, then you may not reach null:, nor a common ancestor. | 19:22 |
| lifeless | we'll still allow a merge commit to be recorded then, though doing the merge is harder :). But this what joining two existing imports or projects does. | 19:23 |
| Peaker | lifeless: then how can you make a meaningful merge? You have a working tree merge, but not a history merge? | 19:23 |
| fullermd | Peaker: Not sure what you mean by 'considered a merge'... | 19:23 |
| Peaker | fullermd: that problem can happen when you merge into trunk, too, can't it? | 19:23 |
| Peaker | fullermd: I mean, why is it a factor against pushing into trunk? | 19:24 |
| Peaker | fullermd: if you push into trunk, you know that if it worked for you in your own development branch, then it will work for trunk, push has the nice property that it will be identical, so you know what's going to be there.. when you merge into a far away branch, you have theoretically no idea what the result is going to be | 19:25 |
| Peaker | lifeless: is there any way to do the opposite, btw? Split the histories of your working tree into separate projects? | 19:26 |
| lifeless | bzr split | 19:26 |
| Peaker | lifeless: ahhh, that explains a few things :-) Now I know why svn plugin uses that format... | 19:26 |
| Peaker | (bzr help split explains a few things, that is) | 19:27 |
| fullermd | Peaker: But pushing into trunk will change the LHS history, which means changing the revnos and the output from log, and I don't want that. | 19:28 |
| fullermd | Peaker: My above statements weren't re: pushing into trunk; they were re: merge requiring a commit. | 19:28 |
| Peaker | fullermd: I see. I don't have enough experience watching revno's/logs to understand that problem you're mentioning, I guess | 19:29 |
| fullermd | The 'rollup' action of log is really handy for those situations. It means my merges into trunk can give a quick description of the changes, and most of the time that's all anybody needs to see. | 19:29 |
| Peaker | fullermd: I do know that when we worked with ClearCase (yikes) there was no pull/push, only merge, so you could endlessly merge from/to trunk and never be sure the trees are identical | 19:29 |
| fullermd | Then they don't need to schluff through the 50 commits it took me to get it right when they're just browsing the history, unless they really need to delve into the internals. | 19:30 |
| Peaker | fullermd: I see, I guess you could use an empty merge from trunk before pushing for that purpose | 19:30 |
| Peaker | fullermd: oh, wait, forget that :) | 19:31 |
| Peaker | fullermd: if you're trusting developers to keep trunk clean and not pqm, then merging into trunk is a little dangerous, isn't it? | 19:31 |
| fullermd | Well, discharging small arms is dangerous, but I still spent Saturday afternoon doing it ;p | 19:32 |
| Peaker | are you into weapons? :) | 19:33 |
| fullermd | Well, that's how I keep cow-orkers from messing up trunk, see. | 19:33 |
| Peaker | most of us in Israel handle weapons at one time or another.. I was stupid enough when I was 18 to test the bullets endurance on its explosive thing, it is not easy to blow :) | 19:34 |
| === mw|lunch is now known as mw | ||
| === mrevell_ is now known as mrevell | ||
| lifeless | jam-laptop_: bzr pqm-submit -m '(robertc) Implement WorkingTree4.update_basis_by_delta giving a 30% performance improvement for commit. (Robert Collins)' | 20:27 |
| lifeless | :) | 20:27 |
| lifeless | commit speed++ | 20:27 |
| mwhudson | lifeless: it would be good to get bzr.dev landings announced in here by some bot | 20:30 |
| beuno | there is a plugin somewhere to have an IRC bot hook into commits | 20:31 |
| lifeless | beuno: bzr.dev commits are done by pqm, on a firewalled machine. | 20:32 |
| lifeless | mwhudson: pity launchpad won't announce to IRC: ) | 20:32 |
| beuno | lifeless, maybe we can have a mirror of bzr.dev and have the bot on a different server? | 20:32 |
| beuno | might have a delay, but still might be usefull | 20:33 |
| lifeless | beuno: well it is announce to the bazaar-commits list | 20:33 |
| beuno | lifeless, that might work too, a bot parsing those emails | 20:34 |
| Peaker | I don't understand how launchpad can be usable until it has shared repo's... it really is insane to upload entire repo/history for every branch | 20:34 |
| beuno | and would speed up a bit | 20:34 |
| lifeless | Peaker: we're looking at addressing the upload overhead there; shared repos are just one way to handle that. | 20:34 |
| Peaker | lifeless: what other ways are there? | 20:35 |
| lifeless | stacked pack repositories looks quite promising and may scale better for a multiuser site like launchpad | 20:37 |
| mwhudson | lifeless: we don't need no new features, mate | 20:38 |
| lifeless | mwhudson: a feature a month keeps the doctor away | 20:40 |
| mwhudson | lifeless: the problem here is the word "a" :) | 20:40 |
| Peaker | lifeless: what are stacked pack repos, compared to ordinary repos? | 20:41 |
| fullermd | Repos with more feminine allure? | 20:42 |
| lifeless | Peaker: a way of combining data from separate repositories | 20:43 |
| fullermd | bzr unionfs. | 20:44 |
| === cfbolz_ is now known as cfbolz | ||
| Peaker | lifeless: when I upload a branch to launchpad, I'd somehow have to tell it that it shares/combines data from another repo if I am to avoid uploading history? would it require explicit data from the user? | 20:45 |
| lifeless | Peaker: magic 8-ball says future hazy, ask again later | 20:48 |
| Peaker | :) | 20:50 |
| lifeless | jam-laptop: it landed :) | 21:14 |
| dato | is somebody tracking what's pending to merge for 0.92, and should I send a patch that splits NEWS in the appropriate place, since 0.92 got branched off? (which leds me to ask: what of bzr.dev is 0.92 material, and how should it get merged, cherry-pick?) | 21:22 |
| lifeless | dato: it will get merged/cherrypicked yes; I'm not sure what commits are what to be honest :) | 21:22 |
| lifeless | poolie will need to make that call as RM | 21:22 |
| === bigdo2 is now known as bigdog | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!