| ToyKeeper | I wonder why bzr allows arbitrary :aliases for branch URLs but restricts it to a hardcoded set. | 00:00 |
|---|---|---|
| ToyKeeper | The bookmarks plugin could be obsoleted by removing that restriction. | 00:00 |
| fullermd | It doesn't allow arbitrary :aliases. | 00:01 |
| lifeless | jelmer: we get significant performance boosts not string joining unnecessarily | 00:03 |
| jelmer | lifeless: What about modifications of individual characters or slices in strings? Does that cause new objects to be created? | 00:04 |
| lifeless | yes | 00:04 |
| ToyKeeper | Ah, I see where it maps those. | 00:05 |
| lifeless | jelmer: "foo" -> "fbo" requires a new string to be created [with some minor exceptions only usable inside the C api] | 00:05 |
| jelmer | lifeless, that's what I figured - so mmap is the only way around it? | 00:05 |
| lifeless | jelmer: without writing C | 00:05 |
| jelmer | hmm | 00:05 |
| pygi | poolie, obviously in a few days | 00:06 |
| lifeless | I'm looking atht his with knits and gc at the moment too, you see | 00:06 |
| pygi | poolie, more text, that is :) | 00:06 |
| poolie | nice | 00:06 |
| jelmer | lifeless, So I'm first going to see how far I can get without writing C extensions for dulwich | 00:06 |
| jelmer | it would be really nice to keep it completely Python | 00:06 |
| jelmer | some of the things I'm looking at are caching the raw texts using a LRUCache | 00:07 |
| pygi | poolie, so can we write the book at that bzr hackfest? :) | 00:07 |
| pygi | and when is that going to take place? | 00:07 |
| mwhudson | you can fake a mutable string with array.array('c') | 00:08 |
| mwhudson | _do not_ write c to modify pystringobjects | 00:08 |
| lifeless | mwhudson: at what cost | 00:08 |
| mwhudson | (not that you were i hope) | 00:08 |
| lifeless | mwhudson: of course not | 00:08 |
| mwhudson | lifeless: depends what you're doing, array objects support the buffer protocol so e.g. writing them to files shouldn't be significantly slower than strings | 00:09 |
| lifeless | mwhudson: probably slice assignment | 00:14 |
| mwhudson | i think in the easy cases that's just an memcpy | 00:15 |
| * markh pipes up that the 'b' format string will turn out to be more py3k-friendly | 00:17 | |
| mwhudson | ah yes, probably | 00:19 |
| mwhudson | i'm a python2 programmer, the difference between b and c confuses me :) | 00:19 |
| markh | me too - but when porting code using 'c' and strings to py3k, it is almost *always* a simple matter of encoding it to bytes and using 'b' - while the py2k version can (optionally) avoid the 'encode' step for str() objects... | 00:21 |
| markh | but still use 'b' as before | 00:21 |
| markh | err - still use 'b' and work as it did before with 'c' | 00:21 |
| lifeless | wow | 00:38 |
| lifeless | 'b' is signed char | 00:38 |
| lifeless | not 'byte' :P | 00:38 |
| fullermd | That's one of those little tricks to make sure people read the docs :p | 00:44 |
| leefmc | would this be the place to ask question about making a bzr mod? | 01:01 |
| lifeless | leefmc: sure | 01:08 |
| leefmc | lifeless: Thanks. | 01:08 |
| leefmc | lifeless: Ok, well a while back i was questioning using bzr for project management, then i went down a few other roads, and finally i've come to the point where i need to make my own project management system. | 01:09 |
| leefmc | Basically just synchronizing folders (with a few other things). | 01:09 |
| leefmc | Now in the end, i can do this, but bzr is so capable of doing this. So i was pondering if it would be easier to make a mod for bzr so that bzr could have a repository inside a branch, or if my own solution would be needed | 01:10 |
| leefmc | lifeless: Any thoughts? | 01:10 |
| lifeless | I don't know quite what you mean by a repository inside a branch | 01:11 |
| leefmc | lifeless: Making a repository, sit inside the directory of a bzr branch. | 01:11 |
| leefmc | lifeless: ie: repo/branchA/repoB/branchB | 01:11 |
| lifeless | uhm | 01:12 |
| lifeless | do you want multiple branches there? | 01:12 |
| leefmc | lifeless: where | 01:12 |
| lifeless | branchA/repoB/branchB{1,2,3,4} ? | 01:12 |
| leefmc | lifeless: repoA or repoB | 01:12 |
| leefmc | well, yes, to both. | 01:12 |
| lifeless | ok, so this is very different to nested trees | 01:12 |
| lifeless | I think | 01:12 |
| leefmc | Well, assuming i understand you.. not really. i dont see how /repoA/branchA/repoB/branchB[1,2,3] is any diff than /repoA/branchA/repoB/branchB | 01:13 |
| lifeless | nested trees don't do repoA/branchA/repoB/branchB | 01:14 |
| lifeless | they do branchA/branchB | 01:14 |
| lifeless | in bzr repositories are *not semantic* | 01:14 |
| lifeless | they are only storage optimisation | 01:14 |
| leefmc | oh i see what you mean, yes, this is very different. I want a repository inside a branch. :) | 01:14 |
| lifeless | well, you seem to want branches in a brnach | 01:15 |
| lifeless | but you keep putting a repository there for some reason I don't quite understand | 01:15 |
| leefmc | no, /repoA/branchA/repoB/branchB, i want repositories inside a branch, heh | 01:15 |
| lifeless | because if you just wanted a repository in a branch, you wouldn't include the branchB | 01:15 |
| leefmc | lifeless: Well if i have a repository inside a branch, what good is it without having branches itself? Perhaps im missing a part of bzr, but isn't there... "nothing" without a branch? | 01:16 |
| leefmc | an empty repo does me no good.. heh, i want to use repoB | 01:16 |
| lifeless | leefmc: right, there isn't anything without a branch, which is why I don't understand why you are asking for a repo in a branch | 01:16 |
| leefmc | hence branchB | 01:16 |
| lifeless | rather than a branch in a branch | 01:16 |
| lifeless | leefmc: *why* do you want repoB to exist | 01:16 |
| leefmc | lifeless: heh, i was hoping i didnt have to go this far :p, but ok. | 01:17 |
| leefmc | This is about project management. | 01:17 |
| lifeless | seriously, why not branchA/branchB{1,2,3} | 01:17 |
| leefmc | im typing | 01:17 |
| leefmc | My need is to have projects be uploaded to a central server, so i can download them from any computer, work on them, then upload, etc. | 01:17 |
| leefmc | Not really revisioning | 01:17 |
| leefmc | Now each project can often have programming projects, some are design, etc. | 01:18 |
| leefmc | Really a project is very generic in my eyes. | 01:18 |
| leefmc | So now with that said, i was hoping to avoid some trouble and use bzr + mod to make this happen. Otherwise im writing a small app for python to scan directories and synchronize everything, etc. | 01:20 |
| leefmc | Now as far as a branch of a branch.. well i dont really want one project polluting another.. I mean, i've never delt with sub branches, but i cant name a branch "pytest" then, because another project might have that heh | 01:20 |
| leefmc | half of my projects have the generic "trunk" for a branch. | 01:21 |
| leefmc | I'd end up naming every branch as "project_name-subproject_type-somename" heh | 01:21 |
| leefmc | In the end, im guessing i'll end up writing a python script :o, you didnt seem to jump up and say "oh its super easy!" so im guessing its easier to go with a custom app of my own. :o | 01:22 |
| leefmc | lifeless: So thanks for the discussion :) (I swear i've had this with you before though haha) | 01:22 |
| lifeless | igc: I've read the log thread; totally at a loss so far - skype if you're awake would be good | 01:22 |
| leefmc | I've actually discussed this very same core problem.. 3 times in this channel? Cept now instead of trying to find an easy side-step to the problem, i just need to get it done right heh. | 01:23 |
| lifeless | leefmc: well, I'm trying to understand | 01:23 |
| lifeless | leefmc: and I don't - if they are things you can just version, just doig 'bzr init' in each 'project' and then using multi-push and multi-pull should be enough | 01:23 |
| lifeless | stop mucking around with 'repositories' - None of your explanations mentioned repositories, so clearly you don't need them | 01:24 |
| fullermd | Well, it IS super easy. You just put it there. But it doesn't DO much of anything. | 01:24 |
| leefmc | lifeless: I thought you needed a repository to have branches/ | 01:24 |
| fullermd | I mean, you can put a unix domain socket inside a branch too. Doesn't mean bzr does anything with it. | 01:24 |
| lifeless | leefmc: NO, repositories are *not semantic* they are totally unecessary | 01:24 |
| leefmc | lifeless: Hmm, so wtf are they for? | 01:25 |
| lifeless | leefmc: they are what bzr stores its history data in | 01:25 |
| leefmc | lifeless: So.. what history is not needed? | 01:25 |
| lifeless | leefmc: if you have many branches of the same code, using a repository to let them share their storage is more efficient | 01:25 |
| lifeless | leefmc: if you haven't manually created a repo, bzr creates one when it needs it | 01:25 |
| AfC | leefmc: they are where your history lives. They can [as an entirely optional optimization that can be useful in some cases] sometimes be shared between branches. | 01:26 |
| lifeless | leefmc: but unless you have multiple branches of the same thing you never need to think about repositories | 01:26 |
| lifeless | leefmc: and you don't have that, from what you are saying | 01:26 |
| leefmc | lifeless: Well.. i do, what if i duplicate a branch of code? | 01:26 |
| lifeless | leefmc: then you have two branches | 01:26 |
| AfC | leefmc: At heart, every Working Tree has a Branch and a Repository. In more advanced layouts they are not in the same place, but in simple cases [ie, starting out] they are co-located. | 01:27 |
| leefmc | lifeless: In otherwords, what do you mean by "multiple branches of the same thing"? | 01:27 |
| AfC | leefmc: you can have as many copies of a branch around as you care to have | 01:27 |
| lifeless | leefmc: multiple branches of the same thing on the same machine | 01:27 |
| AfC | bzr branch A B | 01:27 |
| leefmc | lifeless: Ie, i dont want to run into a problem of bzr "deciding it needs a repository" | 01:27 |
| lifeless | leefmc: there aren't any | 01:27 |
| lifeless | leefmc: I think your problem is that you are thinking about repositories; stop doing that | 01:27 |
| lifeless | leefmc: and it will all become much simpler | 01:28 |
| leefmc | lifeless: Well im only thinking about them because they are the problem, and you just mentioned that bzr will decide if it needs one or not. | 01:28 |
| lifeless | leefmc: humour me | 01:28 |
| lifeless | leefmc: delete the concept from your head for a while | 01:28 |
| AfC | lifeless: (with hindsight I wonder if you guys wouldn't have be better off calling it "Storage" or "Revision Stash" or something; "repository" seems to carry too much baggage for people from the old world, even if it is an accurate term) | 01:29 |
| leefmc | lifeless: Heh, alright, im just afraid of ended up sh*t creek heh | 01:29 |
| lifeless | leefmc: you won't | 01:29 |
| lifeless | leefmc: because Branches are *the key concept* | 01:29 |
| AfC | leefmc: Bazaar never leads you up shit creek. That's what makes it different. | 01:29 |
| fullermd | AfC: "basket" was championed. | 01:29 |
| AfC | fullermd: anything. Doesn't matter. Just not "repository" (again, with hindsight) | 01:30 |
| leefmc | lifeless: So can i have this directory structure? "/brA/brA.A /brA/brA.B /brB/brA.A /brB/brA.B" with no problems? | 01:30 |
| lifeless | yes | 01:30 |
| leefmc | alright, sounds good, i'll give it a shot :) | 01:30 |
| AfC | fullermd: too late now. | 01:31 |
| AfC | fullermd: and nothing wrong with telling people they need to learn the current (ie, this project) actual definition of a term. | 01:31 |
| leefmc | Yea in the quickstart, iirc, repos are added, and i always assumed they were done so for a good reason heh.. i never even would have fathomed that repositories are useless.. heh | 01:31 |
| leefmc | So there is no case where i could find myself missing a repo? | 01:32 |
| AfC | leefmc: they're not useless. They're just something that is internal, and you don't need to think about it right now. | 01:32 |
| leefmc | AfC: Heh, not thinking about something "right now" scares me, when it is the core structure of hundreds of projects i am converting. | 01:33 |
| leefmc | AfC: Thats like not bothering to figure out what an extra piece is. heh | 01:33 |
| AfC | leefmc: changing layout later will not harm you. Branches are the first class entities and are peers. The rest is all supporting infrastructure that comes and goes. All you need to worry about, really, is where your branches are, and where your Working Trees are. For most common uses, the two are the same. | 01:34 |
| leefmc | Not arguing with you guys ofcourse, i obviously know nothing, im just trying to understand where this plays in. I keep getting hints that repos have a use, but then im told to ignore it, and etcetc | 01:34 |
| lifeless | leefmc: I've told you the use, and so has AfC | 01:34 |
| AfC | lifeless: concurr | 01:34 |
| fullermd | More to the point, if you DO decide to bring repos into the mix later, it's *VERY* unlikely that you'd cram them in the middle like that. | 01:35 |
| fullermd | So they wouldn't affect that layer of thinking anyway. | 01:35 |
| lifeless | leefmc: to reiterate: they are used internally for the historical data storage, and can be explicitly configured by users to cause multiple branches with the same history to use the same store | 01:35 |
| AfC | ... but if you don't explicitly do that, no big deal. | 01:35 |
| leefmc | heh | 01:35 |
| AfC | so get on with it already | 01:35 |
| leefmc | AfC: for me it will be "project_branches&trees/projectcodebranchA,projectcodebranchB,projectworkingtree" | 01:36 |
| leefmc | roughly | 01:36 |
| AfC | {shrug} sounds hugely overcomplicated to me, but whatever. | 01:37 |
| leefmc | AfC: It is, using bzr. | 01:37 |
| sii | that reminds me of tlas name-schemes.. :) | 01:37 |
| * sii goes back to lurking | 01:37 | |
| leefmc | sii: Heh, its not a naming scheme, but i had to explain what each folder was | 01:38 |
| AfC | leefmc: look, here's what we do [and this is what is described at http://java-gnome.sourceforge.net/4.0/get/#source ] | 01:38 |
| AfC | leefmc: ~/src/java-gnome is where I collect my branches. | 01:38 |
| AfC | leefmc: *as it happens* I have done `bzr init-repo` there so that all the branches underneath it share storage | 01:38 |
| AfC | leefmc: but I could have easily skipped this | 01:39 |
| leefmc | sii: Really its just a project, and that project can have code in it that needs to be versioned. The project itself is strictly for me, so thats never uploaded to servers, but the code within the project, is uploaded to launchpad/etc | 01:39 |
| lifeless | leefmc: thats all fine | 01:39 |
| leefmc | sii: eg: /projects/some_website/code/trunk && /experimental && /working_tree | 01:40 |
| lifeless | leefmc: that will work fine | 01:40 |
| lifeless | if the projects are very big you may want to init-repo projects | 01:41 |
| lifeless | but if they are small as most website projects are its totally unneeded | 01:41 |
| leefmc | lifeless: So if i type "bzr push" inside of /trunk it will upload to launchpad, but if i "bzr push" inside of "some_website" it will upload it to my local server. Will that local server push include /code/trunk && /working_tree ? | 01:42 |
| leefmc | i assume yes.. but i just figured i'd ask heh | 01:43 |
| lifeless | leefmc: no it won't, because trunk and working_tree are different branches | 01:44 |
| lifeless | leefmc: multipush will I think | 01:44 |
| leefmc | argh :o | 01:44 |
| leefmc | The point being, that i dont wanna push unfinished/committed code of /trunk to launchpad, so i just push my project to my local server. I dont want to have to push/pull 5 different branches everytime i change computers heh. | 01:46 |
| leefmc | I really do thank you all for the help heh | 01:47 |
| AfC | leefmc: then things like ~/src/java-gnome/one and ~/src/java-gnome/two and ~/src/java-gnome/something-else are the branches. That's it | 01:47 |
| leefmc | My apologies for the trouble. Im just as frustrated, trust me heh. | 01:47 |
| leefmc | AfC: Yea i understand that, but in my case, i'd also be pushing java-gnome. Not to mention i dont wanna push /one to launchpad, nor any other branches if they're unfinished, so i end up pushing them to my local server aswell, which also means im giving bzr a new place to push instead of the saved location, so i have to type that in, etc. | 01:49 |
| lifeless | leefmc: grab the multipush plugin and test it out | 01:50 |
| lifeless | leefmc: I feel like I say this every third sentence or so | 01:50 |
| leefmc | On my quickly crap made app for this, i just type one command and it syncs it all, etc. It has problems though, which is why im going all out with the next version of it, but given that i'll be scanning entire file structures and syncing, bzr is so fast for this, i was hoping i could mod it to do that. In the end i think the biggest problem here is my desire to use bzr to do something its not intended for. Its not a workflow that bzr is fi | 01:51 |
| leefmc | t to use, and its not sposed to be heh | 01:51 |
| AfC | leefmc: will, it sounds like your options are a) to use Bazaar the way it's supposed to be used, or b) to write your own version control system. | 01:53 |
| leefmc | AfC: Well thats the great thing, my projects are not in need of versioning, bzr was simply a bonus.. if it could work heh | 01:54 |
| AfC | Whereas, c) constantly saying what you want to do instead of keeping it simple and using the tool for what it is designed for is not an option. | 01:54 |
| leefmc | AfC: Well what i want is what i want heh, if i cant use bzr, so be it heh.. But in reality, that _is_ what i was here asking about.. if bzr would work for it.. | 01:55 |
| AfC | I hope you'll chose (a). At that point, I imagine people around here will be able to help you. | 01:55 |
| leefmc | AfC: Well keep in mind im not abandoning bzr for code versioning.. | 01:55 |
| leefmc | AfC: Im just abandoning it for project management. | 01:56 |
| leefmc | My apologies for asking such a loaded question heh, but you guys did help me find an answer, and i thank you. | 01:58 |
| leefmc | Anyway, i gatta go, i'll be back later, thanks again :) | 01:59 |
| ToyKeeper | D'oh. After pulling the latest, 'bzr.dev info' fails with an error about bzrlib being too new. | 03:15 |
| ToyKeeper | st, log, pull, and other commands are fine though. | 03:16 |
| lifeless | ToyKeeper: could be a plugin | 03:16 |
| ToyKeeper | Yeah, it works without plugins. | 03:17 |
| ToyKeeper | Okay, it was bzr-svn interfering. | 03:18 |
| ToyKeeper | Yay, after getting that fixed, it was really easy to make arbitrary :aliases work. | 03:20 |
| lifeless | I'm not sure why you need that, can't the bookmark plugin just define things freeform? | 03:28 |
| ToyKeeper | Why bother with a bookmark plugin when 4 lines in bzrlib can do the same thing? | 03:30 |
| lifeless | well | 03:31 |
| lifeless | maybe its better? | 03:31 |
| ToyKeeper | Really, this does everything I've ever wanted for bookmarks: http://rafb.net/p/3OKRhr80.html | 03:32 |
| ToyKeeper | echo 'foo_location = file:///tmp/foo/' >> .bzr/branch/branch.conf ; bzr push :foo | 03:33 |
| lifeless | hmmm | 03:35 |
| lifeless | well, I'll let others comment | 03:35 |
| ToyKeeper | I'd imagine it would need a bit more before being acceptable... tests, code to include them in 'bzr info', and a command to set aliases. | 03:37 |
| lifeless | personally, I'd really rather not have a :foo for user defined locations | 03:38 |
| lifeless | just 'foo' | 03:38 |
| ToyKeeper | That would be even better. | 03:38 |
| lifeless | and I don't like NAME_location as a config key | 03:38 |
| ToyKeeper | I don't either. In both cases, I just followed existing convention. | 03:38 |
| lifeless | it makes iteration hard, and can clearly collide with completely unrelated plugins that choose to have something called a THING_location | 03:39 |
| lifeless | well no | 03:39 |
| lifeless | you followed specific case code in bzrlib that doesn't do pattern matching | 03:39 |
| lifeless | and that *has* to avoid colliding with user URL's and paths because its being globally defined by the tool | 03:39 |
| lifeless | neither of which are relevant to your use case: arbitrary names aliases that the user can define | 03:39 |
| ToyKeeper | parent_location and push_location are already used, at least. I'm not sure if the others follow the same pattern. | 03:42 |
| lifeless | the are chosen names | 03:42 |
| lifeless | if a plugin creates e.g. search_parent_location = True | 03:43 |
| lifeless | then doing 'bzr push search_parent' won't try to push to a directory called 'True' | 03:43 |
| ToyKeeper | Yeah, I don't like the _location suffix either. :) | 03:43 |
| lifeless | so don't use it! | 03:43 |
| lifeless | :) | 03:43 |
| fullermd | Also, they're not aliases that we store locations for. They're locations already stored for other reasons, that aliases were added for as a convenience. | 03:43 |
| fullermd | That calls for slightly different implementation than "adding aliases" :) | 03:44 |
| ToyKeeper | If user URLs and special URLs used the same namespace, it might simplify things. | 03:44 |
| ToyKeeper | Anyway, just wanted to check how the general concept went over. | 03:46 |
| fullermd | I'm dearly in favor of the general concept of "in-base user aliases". | 03:47 |
| rousskov | Hello. In a merge bundle, is revision's branch nick encoded anywhere but the <properties><property name="branch-nick"> field? | 04:55 |
| lifeless | each revision has its own nick, which is in the properties | 04:56 |
| lifeless | the bundle also records the branch that the bundle is claiming to be from, but I don't think it grabs the nick of that branch | 04:56 |
| rousskov | Yes. But is it encoded anywhere but the XML element? | 04:56 |
| lifeless | no | 04:57 |
| rousskov | I am changing the XML element, but the commit message after applying the bundle shows the old nick. | 04:57 |
| rousskov | "bzr bundle-info" shows the new nick | 04:57 |
| lifeless | uhm | 04:57 |
| lifeless | if you change the metadata in a revision it won't propogate, bzr assumes that such data is immutable | 04:58 |
| lifeless | revisions are write-once; if you want to change something you need to create a new revision with whatever changes you want made to it | 04:58 |
| lifeless | the rebase plugin can help with this | 04:59 |
| lifeless | but its not a common operation, so not very polished | 04:59 |
| fullermd | I would presume that were it successfully changed, merge would refuse to pull the revs out of the bundle... | 04:59 |
| rousskov | I want to understand what happens first. I have two theories: (a) the nick is encoded in the bundle somewhere else or (b) the old nick gets resurrected from the repository based on revision ID or something like that. | 04:59 |
| lifeless | fullermd: well, properties are advisory metadata not core, so they are not checksummed like tree contents are | 04:59 |
| lifeless | rousskov: its part of a revision object in the repository; if you're working with the bundle in a repo that has seen the erevision before the revision is not decoded out of the bundle - it is skipped over | 05:00 |
| rousskov | lifeless, this sounds like (b). | 05:00 |
| lifeless | rousskov: indeed | 05:01 |
| rousskov | So I should create a brand-new repository, right? So that it has never seen the old commit messages on a private branch? | 05:01 |
| lifeless | rousskov: no, you should create new revision objects rather than trying to edit existing ones | 05:02 |
| rousskov | But I have too many of them. | 05:02 |
| lifeless | rousskov: help me out here :) | 05:02 |
| lifeless | are you talking 10^5 or 10^6 revisions | 05:03 |
| rousskov | I mean I have, say, 100 commits to a private branch. I want to share those commits with the world, but I do not want to share the branch nick | 05:03 |
| lifeless | is the nick the only metadata that you need to change? | 05:03 |
| rousskov | Yes, the only thing I do not want to share. | 05:03 |
| lifeless | ok, two things we need to discuss; first how to make sure you don't have this situation again; do you know of the 'bzr nick' command? | 05:04 |
| rousskov | I could, of course, just apply a dumb patch. I would prefer to preserve the history though. | 05:04 |
| rousskov | lifeless, yes, now I do. But I did not at the time. | 05:04 |
| lifeless | rousskov: ok cool | 05:04 |
| lifeless | now for data cleansing | 05:04 |
| lifeless | this is offhand, but I think the recipe is roughly: | 05:04 |
| lifeless | bzr branch source_branch clean_branch -r before:first_problem_revision | 05:05 |
| lifeless | cd clean_branch | 05:05 |
| lifeless | bzr nick newnick | 05:05 |
| lifeless | bzr rebase ../source_branch | 05:05 |
| lifeless | and it should take a few minuts | 05:05 |
| lifeless | *minutes* | 05:06 |
| rousskov | What is source_branch? The private branch I want to clean? | 05:06 |
| lifeless | yes | 05:06 |
| rousskov | Hm.. Would not before:first_problem_revision simply ignore all the changes on that branch? | 05:07 |
| lifeless | thats the idea | 05:07 |
| lifeless | you want a branch that starts exactly where your current branch started | 05:08 |
| lifeless | then you rebase everything from it to the new branch | 05:08 |
| lifeless | as I recall rebase discards the nick as it goes | 05:08 |
| lifeless | but let me check | 05:08 |
| rousskov | So, if you are right, "rebase" will bring back all the changes, but not the nick? | 05:08 |
| lifeless | oh damn, it will preserve the nick | 05:09 |
| lifeless | gimme a few minutes, I'll whip up a branch of rebase that won't | 05:09 |
| rousskov | FWIW, there were no revisions on the source_branch before the problem_revision. | 05:10 |
| lifeless | rousskov: oh, I was assuming it was squid | 05:10 |
| rousskov | It was branched off a public branch (and all the changes should now go back to that branch). | 05:10 |
| rousskov | You may assume squid, yes. | 05:11 |
| lifeless | so the history of the branch is much deeper than the changes you've made - bzr doesn't record an explicit marker when you run 'bzr branch' - which is why there are revisions before problem_revision on the branch | 05:11 |
| rousskov | OK. Understood. | 05:11 |
| lifeless | this will take a few minutes, my machine is in the middle of a very memory heavy analysis, a little thrashing involved :P | 05:13 |
| rousskov | Thank you for taking the time to help me. | 05:13 |
| lifeless | no probs | 05:14 |
| lifeless | nearly there | 05:33 |
| * rousskov stands by. | 05:43 | |
| lifeless | rousskov: I have it working but with a small caveat that is part of the current rebase UI | 05:50 |
| lifeless | rousskov: I'm going to describe this, and if its ok with you we'll just go ahead, if its not I'll fix that now as well, or at least work around it | 05:50 |
| rousskov | Sure, go ahead | 05:50 |
| lifeless | rousskov: so the caveat is that to rewrite the revisions, rebase wants something *new* in the 'parent' branch its rebasing from. | 05:50 |
| lifeless | think of rebase as moving all your work out of the way, doing a pull, then one by one replaying them back into your branch | 05:51 |
| lifeless | if there isn't anything to pull it assumes it has no changes to make | 05:51 |
| lifeless | (which in this case is false) | 05:51 |
| rousskov | It is easy for me to commit to the dirty (or clean) branch. Is that what is required? | 05:52 |
| lifeless | yes | 05:52 |
| lifeless | just a 'bzr commit -m "Prepare xxx branch" --unchanged' | 05:52 |
| lifeless | will do it | 05:52 |
| lifeless | (don't do it now) | 05:52 |
| rousskov | ^C | 05:52 |
| lifeless | the effect is a single revision in the log that is rather meaningless | 05:52 |
| rousskov | OK. At what point in your original process do I do an empty commit? | 05:53 |
| lifeless | I'll check in a smoke test for this, push the branch and point you at the rebase plugin, and then give you a step by step | 05:53 |
| rousskov | That is what I call service! | 05:54 |
| lifeless | actually, we may not need that little workaround, found a command I thought existed but couldn't find for a bit :P | 05:56 |
| lifeless | let me finish these tests | 05:56 |
| === k4v is now known as m4v | ||
| lifeless | rousskov: ok | 06:14 |
| lifeless | mkdir -p ~/.bazaar/plugins | 06:14 |
| lifeless | bzr branch lp:~lifeless/bzr-rebase/dev ~/.bazaar/plugins/rebase | 06:14 |
| rousskov | Branched 115 revision(s). | 06:15 |
| lifeless | identify the first revision before the revisions you created in the badly nicked branch | 06:15 |
| lifeless | e.g. bzr log | 06:15 |
| lifeless | once you've found that number: | 06:16 |
| lifeless | bzr branch -r THATNUMBER badly-nicked-branch fresh-branch | 06:16 |
| lifeless | cd fresh-branch | 06:16 |
| lifeless | bzr nick NICKYOUWANT | 06:16 |
| lifeless | bzr replay -r -1 ../badly-nicked-branch | 06:16 |
| lifeless | I have some other things I need to do | 06:17 |
| lifeless | I"ll check back in in 10-15 minutes | 06:18 |
| rousskov | Strange: Text conflict in src/cf.data.pre | 06:22 |
| rousskov | lifeless, I resolved the conflict but running "bzr rebase-continue" yields "bzr: ERROR: No rebase to continue" | 06:28 |
| rousskov | Hm. You told me to replay, not rebase, so perhaps that is OK. | 06:30 |
| rousskov | I see many differences between $badly and $fresh so I am guessing replay stopped at some unknown point due to a conflict. | 06:37 |
| rousskov | bzr log in $fresh shows revisions up to and including $THATNUMBER | 06:42 |
| lifeless | rousskov: are you sure you got the right start rev? | 06:48 |
| lifeless | there shouldn't be any conflicts | 06:48 |
| rousskov | It was the smallest revision with bad nick minus 1 | 06:48 |
| rousskov | THATNUMBER=the smallest revision with bad nick minus 1, based on bzr log in $badly | 06:49 |
| lifeless | ok | 06:49 |
| lifeless | lets do rebase then, it could be something odd about replay | 06:50 |
| lifeless | delete fresh-branch | 06:50 |
| lifeless | bzr branch -r THATNUMBER badly-nicked-branch fake-upstream | 06:50 |
| lifeless | bzr branch badly-nicked-branch fresh-branch | 06:50 |
| lifeless | cd fake-upstream | 06:50 |
| lifeless | bzr commit -m "Prepare DESCRIPTION branch" --unchanged | 06:50 |
| lifeless | cd ../fresh-branch | 06:50 |
| lifeless | bzr rebase --new-nick ../fake-upstream | 06:51 |
| rousskov | What is the best way to delete fresh-branch? | 06:51 |
| lifeless | rm -rf | 06:51 |
| rousskov | Would not it remain in the repository? | 06:52 |
| lifeless | yes | 06:52 |
| rousskov | OK | 06:52 |
| lifeless | rousskov: is that working better? | 06:56 |
| rousskov | I am about to run rebase | 06:57 |
| rousskov | Hm. Should I specify nick anywhere? | 06:58 |
| lifeless | in fresh-branch | 06:58 |
| rousskov | So I can leave it as-is if the $fresh directory name is OK, right? | 06:59 |
| lifeless | yes | 06:59 |
| rousskov | It is committing something | 06:59 |
| lifeless | well thats a start | 07:00 |
| rousskov | Done | 07:00 |
| rousskov | Nick appears to be fixed. | 07:01 |
| lifeless | cool | 07:01 |
| lifeless | I'm offf for the night then | 07:01 |
| lifeless | jelmer: when you get up - merge request in lp for it | 07:01 |
| rousskov | lifeless, but the result is not the same branch I started with | 07:03 |
| rousskov | I mean, running "diff -ur $badly $fresh" shows many differences in sources. | 07:03 |
| lifeless | thats unusual | 07:05 |
| lifeless | what do the changes look like | 07:05 |
| rousskov | It looks like some of the changes from the trunk were not pulled in | 07:08 |
| lifeless | thats weird | 07:08 |
| lifeless | uhm | 07:08 |
| rousskov | The $badly branch was synced with trunk a few times | 07:08 |
| lifeless | jelmer: are you around | 07:08 |
| lifeless | rousskov: I'd like to check a factoid or two with rebase' author | 07:09 |
| rousskov | OK. Thanks for all the help so far. | 07:09 |
| lifeless | I'll chat to jelmer my morning, if you can wait | 07:11 |
| rousskov | I probably have to bail very soon :-( | 07:11 |
| lifeless | and see if this known/expected | 07:11 |
| rousskov | The missing changes have lower r number than THATNUMBER | 07:12 |
| lifeless | thats extremely odd | 07:12 |
| rousskov | But they were pulled into the branch later | 07:12 |
| * rousskov is not explaining well | 07:12 | |
| vila | hi all | 07:13 |
| lifeless | if you could drop me a mail perhaps with a little ascii art or something | 07:13 |
| lifeless | I could show it to jelmer (who is european) | 07:13 |
| lifeless | in about 14 hours | 07:13 |
| vila | hey lifeless ! Nice to cross you here ! | 07:13 |
| lifeless | vila: hi, I'm just going in fact | 07:13 |
| vila | I thought so, nice anyway :) | 07:13 |
| rousskov | lifeless, If I do "bzr log" I can see my "merged from parent" message, referring to Amos changes. The original r number for Amos changes is smaller than THATNUMBER but the r number of my commit is higher. | 07:14 |
| rousskov | lifeless, I will send email. | 07:14 |
| lifeless | thanks | 07:17 |
| lifeless | gotta run | 07:17 |
| === asac_ is now known as asac | ||
| === Peng__ is now known as Peng_ | ||
| === asac_ is now known as asac | ||
| === thekorn_ is now known as thekorn | ||
| vila | igc: ping ping, still around by chance ? | 10:51 |
| poolie | hey vila | 11:20 |
| poolie | i'm just off myself though | 11:20 |
| vila | hi poolie ! | 11:20 |
| vila | poolie: still there a few minutes^W seconds ? | 11:21 |
| vila | :) | 11:21 |
| rocky | jelmer: ping | 11:42 |
| rocky | jelmer: just an fyi, the "bzr co" on latest bzr-1.11rc1 and bzr-svn 0.5 branch hangs indefinitely | 11:44 |
| rocky | jelmer: scratch that, false alarm | 11:51 |
| scode | bzr: ERROR: Unknown record type: '\r' | 14:36 |
| scode | A repo suddenly cannot be bramnched, with that error. | 14:36 |
| scode | I know it worked a few pushes ago. | 14:36 |
| scode | The local repo is fine. All I've ever done with the repo is to push things to it over ssh. | 14:36 |
| scode | Anyone recognize it? Google found a bug with a similar problem (though a different character for the unknown record type). | 14:37 |
| james_w | scode: can you grab the backtrace out of ~/.bzr.log? | 14:37 |
| scode | This is with bzr 1.9 (server) and 1.10 (clien). | 14:37 |
| james_w | what was the bug number? | 14:37 |
| scode | james_w: checking | 14:37 |
| scode | james_w: 304848 | 14:37 |
| james_w | bug 304848 | 14:37 |
| ubottu | Launchpad bug 304848 in bzr ""Unrecognised container format" after push" [High,Incomplete] https://launchpad.net/bugs/304848 | 14:38 |
| scode | james_w: Hold on,w ill find a paste bin for the trace. | 14:38 |
| scode | james_w: http://paste.lisp.org/display/73633 | 14:40 |
| james_w | this is over ssh? | 14:40 |
| scode | I may have ctrl-c:ed an operation interactively btw (not sure). But I have always assumed semantics are crash-safe and thus a ctrl-c should always be safe. But it's possible I did. | 14:40 |
| james_w | what ssh server? | 14:40 |
| scode | james_w: The branch is local. | 14:40 |
| scode | james_w: The pushing happened over ssh. | 14:41 |
| scode | james_w: Branching fails over both http and locally (no ssh) | 14:41 |
| james_w | what os did the pushes come from? | 14:41 |
| scode | james_w: FreeBSD 8-CURRENT / Python 2.5 / bzr 1.10. Note that the local repository on my workstation is fine (and can be branched). | 14:42 |
| scode | So the problem only happens when branching from the pushed-to repo. | 14:42 |
| scode | james_w: And the pused-to repos is in a shared repository btw, without a working copy. | 14:42 |
| scode | james_w: Server is FreeBSD 7.0-RELEASE, Python 2.5, bzr 1.9. | 14:42 |
| james_w | it looks like something is corrupt | 14:43 |
| scode | ("server" = machine with the pushed-to repository on it; also the machine on which I did the local branch test that generated the stack trace) | 14:43 |
| james_w | I'm not sure exactly what though | 14:43 |
| james_w | the packs or indices it seems | 14:43 |
| scode | james_w: Yes. Although I of course cannot make guarantees, I feel it is unlikely to be a host system issues. The hardware/server in generla has good track record; nothing suspicious in dmesg; no crash has heppened in between (and besides i'm running w/o write caching). Various services running on the machine; haven't seen any indicators. | 14:44 |
| vadi2 | How can I change the "push branch" location? Even though I pushed to another branch now, bzr is still insisting that default should be the old one | 15:00 |
| Lo-lan-do | bzr push --remember $newurl | 15:01 |
| vadi2 | thanks :) | 15:02 |
| === kiko is now known as kiko-phone | ||
| Lo-lan-do | Is there a simple way of keeping history linear despite commits done with --local? | 15:22 |
| Lo-lan-do | Hm, that wasn't explicit. I'll rephrase. | 15:22 |
| jelmer | Lo-lan-do, bzr rebase --pending-merges | 15:23 |
| Lo-lan-do | Assuming I'm working on a checkout, and for various reasons I do a few commits. | 15:23 |
| LeoNerd | rebase++ | 15:23 |
| Lo-lan-do | jelmer: ♥ | 15:23 |
| Ollie| | i currently use bzr for my source repository on my dev server but am looking to now publish from my dev server to my live server. I will need to do some excludes on the live site e.g. a user upload area. Could someone point me in the right direction of the command(s) i would need to do this? | 15:25 |
| jderemer | hello: im trying to setup a bzr server and i keep getting the following error: errorGeneric bzr smart protocol error: bad request 'GET / HTTP/1.0\r' | 15:26 |
| Lo-lan-do | jelmer: That's more recent than 0.3, though, right? | 15:27 |
| jelmer | Lo-lan-do, yeah, 0.5 I think | 15:27 |
| jelmer | 0.4 | 15:27 |
| Lo-lan-do | Okay. I'll keep the idea for later then. | 15:27 |
| Lo-lan-do | (I reverted to the versions in sid for now, since I do quite a few commits these days) | 15:28 |
| rousskov | jelmer, you are the rebase guru, right? Did Robert/lifeless had a chance to talk to you about using rebase to remove a badly chosen branch nick? He patched the plugin, but the result was not quite what he expected... | 15:42 |
| jelmer | rousskov, yeah, he emailed me about it | 15:44 |
| jelmer | rousskov, rebase doesn't process merges by default | 15:44 |
| jelmer | you have to specify a separate option for that | 15:44 |
| rousskov | Ah | 15:44 |
| rousskov | --always-rebase-merges or --pending-merges? | 15:46 |
| jelmer | --always-rebase-merges | 15:46 |
| rousskov | Thank you. I could not guess which one by reading --help output. Pending where? Already present where? | 15:47 |
| rousskov | Never mind, it is just me, I am sure. | 15:47 |
| * rousskov will retry with --always-rebase-merges | 15:47 | |
| rousskov | I hope this will not screw up future bundles when I submit the changes for merging to trunk. | 15:49 |
| jelmer | screw up in what regard | 15:49 |
| jelmer | ? | 15:49 |
| rousskov | Like a bundle would not apply because it contains revisions that should not be there because they are already in the repository under different IDs or something | 15:50 |
| rousskov | I do not know the internals of how this works so my questions may make no sense at all. | 15:51 |
| rousskov | If you tell me "it will work just fine, the option has no bad side effects", I will be happy :-) | 15:51 |
| jelmer | yes, that will happen - that's why rebase is a bad idea in general | 15:54 |
| rousskov | Hm. So what is the best option in my case? | 15:57 |
| rousskov | Hand-detect missing mergers after running rebase and redo them by hand? | 15:58 |
| jelmer | no, just use --always-rebase-merges | 15:58 |
| jelmer | *any* rebase will break the revision ids | 15:59 |
| rousskov | Ah. | 15:59 |
| rousskov | How do broken revision IDs manifest themselves in practice? | 15:59 |
| jelmer | you get divergedbranches errors | 16:00 |
| rocky | jelmer: i updated the 0.5 branch and the lhs parent error went away but now i got the knit corrupted error (i commented on the launchpad bug regarding it) | 16:01 |
| === rocky1 is now known as rocky | ||
| rousskov | jelmer, sigh. It looks like --always-rebase-merges disabled Robert's plugin changes because the new/fresh branch ended up committed changes with the old nick. | 16:46 |
| rousskov | And it did not help with the missing commits issue either :-(. | 16:48 |
| rousskov | In other words, I got exactly the same result, except all branch commits have the old nick. | 16:49 |
| rockstar | jam, ping | 17:28 |
| jam | hey rockstar | 17:28 |
| rockstar | jam, still on for TWiB today? | 17:28 |
| rockstar | jam, also, did you see that I replied to that bzr-stats merge proposal from about 6 months ago? :) | 17:32 |
| jam | rockstar: yeah I saw that, jelmer approved it, did you need me to specifically merge it? | 17:33 |
| rockstar | jam, well, not you specifically, but would like it merge please. | 17:33 |
| rockstar | Er, merged. English and its tenses... | 17:34 |
| jelmer | I already merged it | 17:35 |
| === bac is now known as bac_lunch | ||
| rockstar | jelmer, hooray! | 17:42 |
| rocky | jelmer: did you see my comment earlier ? (i got dc'd) regarding the knit corruption error ? | 17:57 |
| === sdboyer_ is now known as sdboyer | ||
| === bac_lunch is now known as bac | ||
| jelmer | rocky, yep | 19:12 |
| === christoph_ is now known as enigma42 | ||
| === thumper_laptop is now known as thumper | ||
| dereine | hi | 21:46 |
| dereine | is it possible to get a diff of every changed version of a file? | 21:46 |
| lifeless | dereine: all the changes made to a single file? | 21:47 |
| dereine | yes | 21:47 |
| lifeless | yes, but not with a single command | 21:48 |
| dereine | ah ok is it possible to see th version when something changed? | 21:48 |
| lifeless | log FILE will report all the revisions that changed/renamed/merged the file, and bzr diff -r before:rev..rev PATH will givethe diff | 21:48 |
| dereine | thx | 21:48 |
| beuno | dereine, and bzr annotate FILE will tell you the last revision that changed each line | 21:49 |
| lifeless | you may also like 'bzr annotate FILE' | 21:49 |
| lifeless | or 'bzr gannotate FILE' | 21:49 |
| fullermd | diff -crev would be shorter | 21:49 |
| LarstiQ | or `bzr qannotate` (or via qbrowse, which is what I usually do) | 21:49 |
| dereine | thx | 21:49 |
| dereine | ok i will never ask is it possible | 21:50 |
| LarstiQ | dereine: failing that, via bzrlib ;) | 21:50 |
| dereine | LarstiQ: bzr is just awesome i have a usbstick with a win/lin version, i can stick in everywhere and get all my projects from my ftp only repo | 21:51 |
| LarstiQ | dereine: I'm glad you like it :) | 21:51 |
| dereine | i just have to bring other people to use it, i know some people, they don't use any control versioning system | 21:52 |
| fullermd | Hey, I know insane people too. | 21:53 |
| dereine | i'm just happy to use bzr local for this project | 21:53 |
| dereine | i have to say, which file i changed | 21:55 |
| dereine | everytime! | 21:55 |
| poolie | hello all | 22:05 |
| GaryvdM | Hi poolie | 22:07 |
| poolie | hello Gary | 22:08 |
| pickscrape | How do I get a list of the things on my shelf using the new shelf? (e.g. equivalent of bzr shelf list) | 22:10 |
| vila | bzr shelve --list | 22:10 |
| vila | pickscrape: I think you need 1.11 though | 22:10 |
| pickscrape | Yeah, just discovered that. :( | 22:10 |
| * pickscrape digs in .bzr/checkout/shelf/ | 22:11 | |
| vila | what ? -- list :-) or you have only 1.10 :-( ? | 22:11 |
| pickscrape | That I only have 1.10 | 22:11 |
| vila | Why don't you upgrade ? | 22:11 |
| pickscrape | I'm sticking with what the PPA gives me. 1.11 is still in RC isn't it? | 22:12 |
| pickscrape | Though I might be forced to upgrade... 1.10 offers no facility to unshelve anything other than the most recent does it (stack-style). | 22:13 |
| vila | pickscrape: Ok, but I think 1.11final is for today (australian time) though | 22:13 |
| pickscrape | oh right | 22:13 |
| pickscrape | vila: I'm wrong anyway: it does let you unshelve an arbitrary shelf ID. | 22:14 |
| vila | here you go... | 22:14 |
| vila | Don't put too much on your shelve anyway :-) | 22:15 |
| pickscrape | I just use it when I have to switch branches. Normally it's empty, I'm just in a bit of a tizz at the moment. :) | 22:15 |
| pickscrape | I should qualify: when i have to switch branches mid-development. | 22:16 |
| xokaido | hello all... | 22:41 |
| xokaido | is anyone here?... | 22:42 |
| thumper | yes | 22:42 |
| xokaido | hello... :) | 22:42 |
| fullermd | No. We left early to get boozed up. | 22:42 |
| xokaido | I have a little problem in bzr trying to commit my changes using FTP... | 22:43 |
| xokaido | an SFTP too... | 22:43 |
| xokaido | the problem is it throws error saying: "FTP temporary error: 451 /PROJECT/.bzr/repository/upload/bx526oqloa4dovzp8ji5.fetch: Append/Restart not permitted, try again. Retrying" | 22:43 |
| xokaido | does anyone have idea what to do?.. | 22:44 |
| fullermd | That falls into the category "FTP is too damn weird, and your FTP server is broken" | 22:44 |
| xokaido | fullermd, thx for your reply, but FTP server works just fine... | 22:44 |
| fullermd | Well, no it doesn't. If it did, the APPE would work :p | 22:44 |
| xokaido | it has no problems other then with bzr... | 22:44 |
| fullermd | What's the problem over SFTP? | 22:45 |
| xokaido | it simply can't see the branch... | 22:45 |
| xokaido | it says there is no branch... | 22:45 |
| fullermd | Oh. How nice of it. | 22:45 |
| fullermd | You sure it's looking at the right path? | 22:45 |
| beuno | xokaido, sometimes you need to specify the full path over sftp | 22:45 |
| xokaido | yes, I do... | 22:45 |
| fullermd | (specifically, it will work from / if you don't put a ~ in it) | 22:45 |
| xokaido | because with bzr log ftp:// it shows correct log... | 22:46 |
| beuno | fullermd, I think bzr doesn't expand ~? | 22:46 |
| fullermd | bzr+ssh doesn't. sftp deos. | 22:46 |
| fullermd | And does, too. | 22:46 |
| beuno | xokaido, did you try both variants? relative and absolute path? | 22:46 |
| fullermd | xokaido: Try sftp://server/~/[path] | 22:46 |
| xokaido | beuno, thank you very much, with full path sftp works... :) | 22:46 |
| xokaido | but how about ftp?... | 22:46 |
| fullermd | FTP is a wonky protocol. That it ever works is kinda astonishing. | 22:47 |
| xokaido | is there a chance to get it to work?... | 22:47 |
| beuno | xokaido, FTP, as fullermd says, your server is probably "broken" | 22:47 |
| fullermd | The problem here is that your server is refusing to APPE[nd], and to compound the sin is giving a TEMPORARY failure for it. | 22:47 |
| beuno | or "not working as well as it could" | 22:47 |
| fullermd | If it actually gave a "No, sorry, I don't support APPE", I think bzr would actually work around it. | 22:47 |
| fullermd | But since it's a temporary failure, we just keep retrying (like it said to), and it never works ('cuz it's broken) | 22:47 |
| fullermd | For some reason, this is apparently a really common failure with FTP servers. I don't know why. | 22:48 |
| xokaido | fullermd, thank you very much... can I fix this somehow?... | 22:48 |
| fullermd | Not short of replacing the server software, no. | 22:48 |
| fullermd | But if SFTP works, it's probably a lot better all around anyway. | 22:48 |
| jelmer | lifeless, awake yet? | 22:49 |
| xokaido | yes, in this way I can work with SFTP but in other situation I will need FTP... | 22:49 |
| * fullermd will be a happy, happy camper on the day when the last FTP server can be shut off forever... | 22:49 | |
| xokaido | :) | 22:49 |
| fullermd | Well, since SFTP works here, the FTP case would be on a different server. So maybe it'll have a different daemon running ;) | 22:49 |
| xokaido | fullermd, thank you once again for your attention... we hope other FTP server would work better... :) | 22:50 |
| fullermd | It's probably possible bzr could be hacked to handle that case better. | 22:51 |
| lifeless | jelmer: yes | 22:54 |
| lifeless | jelmer: was just on a call | 22:55 |
| xokaido | one more problem... :-( | 22:55 |
| lifeless | beuno: sftp://host/~/ is the same as scp host: | 22:55 |
| lifeless | sftp://host/ is the same as scp host:/ | 22:55 |
| xokaido | am trying to use cdiff from bzrtools, but it says: "Plugin "Bzrtools" is not up to date with installed Bazaar version 1.6.1" | 22:56 |
| xokaido | but it was the latest... :-( | 22:56 |
| lifeless | xokaido: latest from where? | 22:57 |
| xokaido | from bazaar website | 22:57 |
| xokaido | http://bazaar-vcs.org | 22:57 |
| xokaido | from here... | 22:57 |
| lifeless | xokaido: the message may be misleading then, because bzrtools definitely had a 1.6 compatible release; bzr itself is up to 1.10 now | 22:58 |
| jam | poolie: ping | 22:58 |
| jam | Just a quick comment about the new progress bars that you merged | 22:58 |
| jam | It seems to be nesting things incorrectly | 22:58 |
| xokaido | bzr version shows this: "Bazaar (bzr) 1.6.1" | 22:58 |
| jam | I sent something to the list | 22:59 |
| lifeless | xokaido: yes, and if you got the latest bzrtools, then you will have bzrtools for 1.10 | 22:59 |
| jam | But it seemed like something that you would want to look at directly. | 22:59 |
| fullermd | Or 1.11. | 22:59 |
| xokaido | lifeless, how can I fix this?... | 22:59 |
| poolie | jam: pong | 22:59 |
| poolie | i'll check it out | 22:59 |
| lifeless | xokaido: well, install matching versions | 23:00 |
| fullermd | xokaido: It's got a list of old versions; find the 1.6.x one and grab that. | 23:00 |
| lifeless | xokaido: I don't know how you installed bzr or bzrtools; but 'however you installed them'. | 23:00 |
| xokaido | you mean bzr itself or just tools?. | 23:00 |
| lifeless | xokaido: you can either upgrade bzr to a version matching bzrtools, or downgrade bzrtools to a version matching your bzr | 23:00 |
| xokaido | how do I upgrade bzr?... is there bzr checkout ? | 23:01 |
| jam | thanks | 23:01 |
| GaryvdM | xokaido: how did you install bzr? | 23:01 |
| xokaido | GaryvdM, from slackware package... | 23:02 |
| xokaido | I downloaded it from bzr website... | 23:02 |
| xokaido | I have experience neither in svn nor in cvs... :-( | 23:02 |
| xokaido | but bzr seems to be the coolest thing... | 23:03 |
| jelmer | lifeless, so, stacked branches rely on versionedfiles very much at the moment | 23:03 |
| xokaido | I could quickly understand what's going on... | 23:03 |
| jelmer | lifeless: and versionedfiles don't match svn very well, so it would be nice to have somewhat more dedicated API's available that don't require serialization of revisions, etc. | 23:04 |
| GaryvdM | xokaido: Not sure who did that package. Need to nudge them to update it. | 23:04 |
| xokaido | GaryvdM, I'll try to reinstall it using sources... | 23:05 |
| lifeless | jelmer: indeed it would | 23:07 |
| lifeless | jelmer: did you see my query about rebase | 23:07 |
| jelmer | lifeless, I did see it and chatted with him here on IRC a bit | 23:11 |
| xokaido | GaryvdM, thank you very much... it works now just fine... :-) | 23:12 |
| lifeless | the special thing seems to be that the merges were of branches from the same branch point | 23:12 |
| lifeless | I'm wondering if there is an off-by-one error in there somewhere | 23:12 |
| jelmer | lifeless: could be, I think there's another open bug about this | 23:14 |
| lifeless | where in the code is the 'I should skip a rev' logic | 23:14 |
| LarstiQ | hmm | 23:14 |
| lifeless | jelmer: also was the patch ok | 23:15 |
| jelmer | lifeless: generate_simple_plan() | 23:15 |
| LarstiQ | oh that's precious | 23:16 |
| xokaido | wow, the coolest plugin is the 'shell' command in bzr.... much thanks to the author... :-) | 23:19 |
| lifeless | LarstiQ: whats precious | 23:19 |
| * xokaido says: thank you guys all... | 23:20 | |
| LarstiQ | lifeless: it seems it is already reported as https://bugs.edge.launchpad.net/bzr/+bug/82555 | 23:22 |
| ubottu | Launchpad bug 82555 in bzr "Merging to an empty branch doesn't work" [Medium,Confirmed] | 23:22 |
| LarstiQ | lifeless: merging into an empty branch. bzr log of all of it shows me one revision, with revno 5 in this case. | 23:23 |
| lifeless | score | 23:24 |
| lifeless | branch version? | 23:24 |
| LarstiQ | lifeless: Branch format 6, if that is what you're asking | 23:27 |
| lifeless | yeah | 23:27 |
| LarstiQ | I was trying to reproduce a bug where the revnos would go into the negatives | 23:27 |
| LarstiQ | but either I forgot how to do that, or it has since been fixed | 23:27 |
| LarstiQ | or well, bugs differently | 23:27 |
| mwhudson | oh that's interesting | 23:28 |
| mwhudson | i've seen borked branches in a state like that | 23:28 |
| rousskov | lifeless, thanks for following up. Jelmer told me to use --always-rebase-merges but that had no effect except for disabling your nick hack (I got old nicks after completing the same procedure). | 23:50 |
| rousskov | I have a bad feeling about this. Perhaps we tried too hard and now the repository is not in the expected state, toying with us. | 23:51 |
| rousskov | lifeless, why do you not recommend editing the <nick> field in a bundle and applying the bundle to a fresh branch in a fresh repository? Is it going to screw things up in the future? | 23:52 |
| LarstiQ | I'd assume the nick is included in all the hashes etc | 23:53 |
| rousskov | Does not look like it. | 23:53 |
| rousskov | The edited bundle applies cleanly. | 23:53 |
| LarstiQ | really? | 23:53 |
| LarstiQ | does it also apply that nick? | 23:53 |
| rousskov | bzr bundle-info works, etc. | 23:53 |
| rousskov | No. That's the problem. | 23:53 |
| LarstiQ | you edited in the for-human text part, or in the encoded machine readable part? | 23:53 |
| rousskov | The theory is that the repository already saw those revisions so it just skips them. | 23:54 |
| james_w | the nick is stored in the revision | 23:54 |
| LarstiQ | Ah, or that. | 23:54 |
| rousskov | I edited the machine readable part. | 23:54 |
| LarstiQ | rousskov: so yeah, then you'd effectively be creating more than one content for a given revision, thereby violating an important invariant | 23:54 |
| LarstiQ | rousskov: ok | 23:54 |
| lifeless | rousskov: several reasons; you want to prevent disclosure of that data; its extremely hard to be sure that you won't disclose it if the revids are the ame | 23:55 |
| rousskov | but what if I do not care about the revision with the old nick? I am willing to dump/delete it. | 23:55 |
| lifeless | secondly folk ask for this sort of history edit from time to time; I think its important to have a simple slick answer | 23:55 |
| LarstiQ | fair enough | 23:56 |
| LarstiQ | rousskov: I don't know your situation exactly, but you could use the remove-revisions (or similary named) plugin to punch that revision out. | 23:56 |
| lifeless | LarstiQ: the revision contents are fine | 23:56 |
| rousskov | I would love a simple slick answer as long as it is not a "no, you should have thought about it earlier" | 23:56 |
| lifeless | rousskov: clearly thats not an answer | 23:57 |
| rousskov | not yet :-) | 23:57 |
| sevenseeker | can I use bzr-svn on an existing svn workingcopy? | 23:57 |
| rousskov | LarstiQ, So you recommend a) generating a bundle b) removing old revisions c) applying the edited bundle? | 23:58 |
| lifeless | rousskov: so, --always-rebase-merges is needed | 23:58 |
| jelmer | sevenseeker, yes | 23:58 |
| lifeless | rousskov: I think its a bug that its needed, because bzr has enough info to tell that the merge is needed | 23:58 |
| lifeless | jelmer: ^ for discussion | 23:58 |
| lifeless | rousskov: what happened when you tried with --always-rebase-merges --new-nick ? | 23:58 |
| LarstiQ | rousskov: I hesitate to recommend things, I don't have enough information and wouldn't like to irrevocably destroy your data. | 23:58 |
| rousskov | I got old nick and same missing revisions. | 23:59 |
| * LarstiQ trusts lifeless to help rousskov out. | 23:59 | |
| rousskov | LarstiQ, post your lawyer's address just in case anyway. | 23:59 |
| LarstiQ | it being almost 01:00, it's waaay past my bedtime anyway. | 23:59 |
| LarstiQ | rousskov: :) | 23:59 |
| lifeless | jelmer: ping, can we spend some time on this | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!