ToyKeeperI wonder why bzr allows arbitrary :aliases for branch URLs but restricts it to a hardcoded set.00:00
ToyKeeperThe bookmarks plugin could be obsoleted by removing that restriction.00:00
fullermdIt doesn't allow arbitrary :aliases.00:01
lifelessjelmer: we get significant performance boosts not string joining unnecessarily00:03
jelmerlifeless: What about modifications of individual characters or slices in strings? Does that cause new objects to be created?00:04
ToyKeeperAh, I see where it maps those.00:05
lifelessjelmer: "foo" -> "fbo" requires a new string to be created [with some minor exceptions only usable inside the C api]00:05
jelmerlifeless, that's what I figured - so mmap is the only way around it?00:05
lifelessjelmer: without writing C00:05
pygipoolie, obviously in a few days00:06
lifelessI'm looking atht his with knits and gc at the moment too, you see00:06
pygipoolie, more text, that is :)00:06
jelmerlifeless, So I'm first going to see how far I can get without writing C extensions for dulwich00:06
jelmerit would be really nice to keep it completely Python00:06
jelmersome of the things I'm looking at are caching the raw texts using a LRUCache00:07
pygipoolie, so can we write the book at that bzr hackfest? :)00:07
pygiand when is that going to take place?00:07
mwhudsonyou can fake a mutable string with array.array('c')00:08
mwhudson_do not_ write c to modify pystringobjects00:08
lifelessmwhudson: at what cost00:08
mwhudson(not that you were i hope)00:08
lifelessmwhudson: of course not00:08
mwhudsonlifeless: depends what you're doing, array objects support the buffer protocol so e.g. writing them to files shouldn't be significantly slower than strings00:09
lifelessmwhudson: probably slice assignment00:14
mwhudsoni think in the easy cases that's just an memcpy00:15
* markh pipes up that the 'b' format string will turn out to be more py3k-friendly00:17
mwhudsonah yes, probably00:19
mwhudsoni'm a python2 programmer, the difference between b and c confuses me :)00:19
markhme 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
markhbut still use 'b' as before00:21
markherr - still use 'b' and work as it did before with 'c'00:21
lifeless'b' is signed char00:38
lifelessnot 'byte' :P00:38
fullermdThat's one of those little tricks to make sure people read the docs  :p00:44
leefmcwould this be the place to ask  question about making a bzr mod?01:01
lifelessleefmc: sure01:08
leefmclifeless: Thanks.01:08
leefmclifeless: 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
leefmcBasically just synchronizing folders (with a few other things).01:09
leefmcNow 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 needed01:10
leefmclifeless: Any thoughts?01:10
lifelessI don't know quite what you mean by a repository inside a branch01:11
leefmclifeless: Making a repository, sit inside the directory of a bzr branch.01:11
leefmclifeless: ie: repo/branchA/repoB/branchB01:11
lifelessdo you want multiple branches there?01:12
leefmclifeless: where01:12
lifelessbranchA/repoB/branchB{1,2,3,4} ?01:12
leefmclifeless: repoA or repoB01:12
leefmcwell, yes, to both.01:12
lifelessok, so this is very different to nested trees01:12
lifelessI think01:12
leefmcWell, assuming i understand you.. not really. i dont see how /repoA/branchA/repoB/branchB[1,2,3] is any diff than /repoA/branchA/repoB/branchB01:13
lifelessnested trees don't do repoA/branchA/repoB/branchB01:14
lifelessthey do branchA/branchB01:14
lifelessin bzr repositories are *not semantic*01:14
lifelessthey are only storage optimisation01:14
leefmcoh i see what you mean, yes, this is very different. I want a repository inside a branch. :)01:14
lifelesswell, you seem to want branches in a brnach01:15
lifelessbut you keep putting a repository there for some reason I don't quite understand01:15
leefmcno, /repoA/branchA/repoB/branchB, i want repositories inside a branch, heh01:15
lifelessbecause if you just wanted a repository in a branch, you wouldn't include the branchB01:15
leefmclifeless: 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
leefmcan empty repo does me no good.. heh, i want to use repoB01:16
lifelessleefmc: right, there isn't anything without a branch, which is why I don't understand why you are asking for a repo in a branch01:16
leefmchence branchB01:16
lifelessrather than a branch in a branch01:16
lifelessleefmc: *why* do you want repoB to exist01:16
leefmclifeless: heh, i was hoping i didnt have to go this far :p, but ok.01:17
leefmcThis is about project management.01:17
lifelessseriously, why not branchA/branchB{1,2,3}01:17
leefmcim typing01:17
leefmcMy 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
leefmcNot really revisioning01:17
leefmcNow each project can often have programming projects, some are design, etc.01:18
leefmcReally a project is very generic in my eyes.01:18
leefmcSo 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
leefmcNow 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 heh01:20
leefmchalf of my projects have the generic "trunk" for a branch.01:21
leefmcI'd end up naming every branch as "project_name-subproject_type-somename" heh01:21
leefmcIn 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. :o01:22
leefmclifeless: So thanks for the discussion :) (I swear i've had this with you before though haha)01:22
lifelessigc: I've read the log thread; totally at a loss so far - skype if you're awake would be good01:22
leefmcI'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
lifelessleefmc: well, I'm trying to understand01:23
lifelessleefmc: 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 enough01:23
lifelessstop mucking around with 'repositories' - None of your explanations mentioned repositories, so clearly you don't need them01:24
fullermdWell, it IS super easy.  You just put it there.  But it doesn't DO much of anything.01:24
leefmclifeless: I thought you needed a repository to have branches/01:24
fullermdI mean, you can put a unix domain socket inside a branch too.  Doesn't mean bzr does anything with it.01:24
lifelessleefmc: NO, repositories are *not semantic* they are totally unecessary01:24
leefmclifeless: Hmm, so wtf are they for?01:25
lifelessleefmc: they are what bzr stores its history data in01:25
leefmclifeless: So.. what history is not needed?01:25
lifelessleefmc: if you have many branches of the same code, using a repository to let them share their storage is more efficient01:25
lifelessleefmc: if you haven't manually created a repo, bzr creates one when it needs it01:25
AfCleefmc: 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
lifelessleefmc: but unless you have multiple branches of the same thing you never need to think about repositories01:26
lifelessleefmc: and you don't have that, from what you are saying01:26
leefmclifeless: Well.. i do, what if i duplicate a branch of code?01:26
lifelessleefmc: then you have two branches01:26
AfCleefmc: 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
leefmclifeless: In otherwords, what do you mean by "multiple branches of the same thing"?01:27
AfCleefmc: you can have as many copies of a branch around as you care to have01:27
lifelessleefmc: multiple branches of the same thing on the same machine01:27
AfCbzr branch A B01:27
leefmclifeless: Ie, i dont want to run into a problem of bzr "deciding it needs a repository"01:27
lifelessleefmc: there aren't any01:27
lifelessleefmc: I think your problem is that you are thinking about repositories; stop doing that01:27
lifelessleefmc: and it will all become much simpler01:28
leefmclifeless: 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
lifelessleefmc: humour me01:28
lifelessleefmc: delete the concept from your head for a while01:28
AfClifeless: (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
leefmclifeless: Heh, alright, im just afraid of ended up sh*t creek heh01:29
lifelessleefmc: you won't01:29
lifelessleefmc: because Branches are *the key concept*01:29
AfCleefmc: Bazaar never leads you up shit creek. That's what makes it different.01:29
fullermdAfC: "basket" was championed.01:29
AfCfullermd: anything. Doesn't matter. Just not "repository" (again, with hindsight)01:30
leefmclifeless: So can i have this directory structure? "/brA/brA.A /brA/brA.B /brB/brA.A /brB/brA.B" with no problems?01:30
leefmcalright, sounds good, i'll give it a shot :)01:30
AfCfullermd: too late now.01:31
AfCfullermd: and nothing wrong with telling people they need to learn the current (ie, this project) actual definition of a term.01:31
leefmcYea 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.. heh01:31
leefmcSo there is no case where i could find myself missing a repo?01:32
AfCleefmc: they're not useless. They're just something that is internal, and you don't need to think about it right now.01:32
leefmcAfC: Heh, not thinking about something "right now" scares me, when it is the core structure of hundreds of projects i am converting.01:33
leefmcAfC: Thats like not bothering to figure out what an extra piece is. heh01:33
AfCleefmc: 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
leefmcNot 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 etcetc01:34
lifelessleefmc: I've told you the use, and so has AfC01:34
AfClifeless: concurr01:34
fullermdMore 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
fullermdSo they wouldn't affect that layer of thinking anyway.01:35
lifelessleefmc: 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 store01:35
AfC... but if you don't explicitly do that, no big deal.01:35
AfCso get on with it already01:35
leefmcAfC: for me it will be "project_branches&trees/projectcodebranchA,projectcodebranchB,projectworkingtree"01:36
AfC{shrug} sounds hugely overcomplicated to me, but whatever.01:37
leefmcAfC: It is, using bzr.01:37
siithat reminds me of tlas name-schemes.. :)01:37
* sii goes back to lurking01:37
leefmcsii: Heh, its not a naming scheme, but i had to explain what each folder was01:38
AfCleefmc: look, here's what we do [and this is what is described at  http://java-gnome.sourceforge.net/4.0/get/#source ]01:38
AfCleefmc: ~/src/java-gnome is where I collect my branches.01:38
AfCleefmc: *as it happens* I have done `bzr init-repo` there so that all the branches underneath it share storage01:38
AfCleefmc: but I could have easily skipped this01:39
leefmcsii: 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/etc01:39
lifelessleefmc: thats all fine01:39
leefmcsii: eg: /projects/some_website/code/trunk && /experimental && /working_tree01:40
lifelessleefmc: that will work fine01:40
lifelessif the projects are very big you may want to init-repo projects01:41
lifelessbut if they are small as most website projects are its totally unneeded01:41
leefmclifeless: 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
leefmci assume yes.. but i just figured i'd ask heh01:43
lifelessleefmc: no it won't, because trunk and working_tree are different branches01:44
lifelessleefmc: multipush will I think01:44
leefmcargh :o01:44
leefmcThe 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
leefmcI really do thank you all for the help heh01:47
AfCleefmc: then things like ~/src/java-gnome/one and ~/src/java-gnome/two and ~/src/java-gnome/something-else are the branches. That's it01:47
leefmcMy apologies for the trouble. Im just as frustrated, trust me heh.01:47
leefmcAfC: 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
lifelessleefmc: grab the multipush plugin and test it out01:50
lifelessleefmc: I feel like I say this every third sentence or so01:50
leefmcOn 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 fi01:51
leefmct to use, and its not sposed to be heh01:51
AfCleefmc: 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
leefmcAfC: Well thats the great thing, my projects are not in need of versioning, bzr was simply a bonus.. if it could work heh01:54
AfCWhereas, 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
leefmcAfC: 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
AfCI hope you'll chose (a). At that point, I imagine people around here will be able to help you.01:55
leefmcAfC: Well keep in mind im not abandoning bzr for code versioning..01:55
leefmcAfC: Im just abandoning it for project management.01:56
leefmcMy apologies for asking such a loaded question heh, but you guys did help me find an answer, and i thank you.01:58
leefmcAnyway, i gatta go, i'll be back later, thanks again :)01:59
ToyKeeperD'oh.  After pulling the latest, 'bzr.dev info' fails with an error about bzrlib being too new.03:15
ToyKeeperst, log, pull, and other commands are fine though.03:16
lifelessToyKeeper: could be a plugin03:16
ToyKeeperYeah, it works without plugins.03:17
ToyKeeperOkay, it was bzr-svn interfering.03:18
ToyKeeperYay, after getting that fixed, it was really easy to make arbitrary :aliases work.03:20
lifelessI'm not sure why you need that, can't the bookmark plugin just define things freeform?03:28
ToyKeeperWhy bother with a bookmark plugin when 4 lines in bzrlib can do the same thing?03:30
lifelessmaybe its better?03:31
ToyKeeperReally, this does everything I've ever wanted for bookmarks:  http://rafb.net/p/3OKRhr80.html03:32
ToyKeeperecho 'foo_location = file:///tmp/foo/' >> .bzr/branch/branch.conf ; bzr push :foo03:33
lifelesswell, I'll let others comment03:35
ToyKeeperI'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
lifelesspersonally, I'd really rather not have a :foo for user defined locations03:38
lifelessjust 'foo'03:38
ToyKeeperThat would be even better.03:38
lifelessand I don't like NAME_location as a config key03:38
ToyKeeperI don't either.  In both cases, I just followed existing convention.03:38
lifelessit makes iteration hard, and can clearly collide with completely unrelated plugins that choose to have something called a THING_location03:39
lifelesswell no03:39
lifelessyou followed specific case code in bzrlib that doesn't do pattern matching03:39
lifelessand that *has* to avoid colliding with user URL's and paths because its being globally defined by the tool03:39
lifelessneither of which are relevant to your use case: arbitrary names aliases that the user can define03:39
ToyKeeperparent_location and push_location are already used, at least.  I'm not sure if the others follow the same pattern.03:42
lifelessthe are chosen names03:42
lifelessif a plugin creates e.g. search_parent_location = True03:43
lifelessthen doing 'bzr push search_parent' won't try to push to a directory called 'True'03:43
ToyKeeperYeah, I don't like the _location suffix either.  :)03:43
lifelessso don't use it!03:43
fullermdAlso, 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
fullermdThat calls for slightly different implementation than "adding aliases"  :)03:44
ToyKeeperIf user URLs and special URLs used the same namespace, it might simplify things.03:44
ToyKeeperAnyway, just wanted to check how the general concept went over.03:46
fullermdI'm dearly in favor of the general concept of "in-base user aliases".03:47
rousskovHello. In a merge bundle, is revision's branch nick encoded anywhere but the <properties><property name="branch-nick"> field?04:55
lifelesseach revision has its own nick, which is in the properties04:56
lifelessthe bundle also records the branch that the bundle is claiming to be from, but I don't think it grabs the nick of that branch04:56
rousskovYes. But is it encoded anywhere but the XML element?04:56
rousskovI 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 nick04:57
lifelessif you change the metadata in a revision it won't propogate, bzr assumes that such data is immutable04:58
lifelessrevisions are write-once; if you want to change something you need to create a new revision with whatever changes you want made to it04:58
lifelessthe rebase plugin can help with this04:59
lifelessbut its not a common operation, so not very polished04:59
fullermdI would presume that were it successfully changed, merge would refuse to pull the revs out of the bundle...04:59
rousskovI 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
lifelessfullermd: well, properties are advisory metadata not core, so they are not checksummed like tree contents are04:59
lifelessrousskov: 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 over05:00
rousskovlifeless, this sounds like (b).05:00
lifelessrousskov: indeed05:01
rousskovSo I should create a brand-new repository, right? So that it has never seen the old commit messages on a private branch?05:01
lifelessrousskov: no, you should create new revision objects rather than trying to edit existing ones05:02
rousskovBut I have too many of them.05:02
lifelessrousskov: help me out here :)05:02
lifelessare you talking 10^5 or 10^6 revisions05:03
rousskovI 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 nick05:03
lifelessis the nick the only metadata that you need to change?05:03
rousskovYes, the only thing I do not want to share.05:03
lifelessok, 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
rousskovI could, of course, just apply a dumb patch. I would prefer to preserve the history though.05:04
rousskovlifeless, yes, now I do. But I did not at the time.05:04
lifelessrousskov: ok cool05:04
lifelessnow for data cleansing05:04
lifelessthis is offhand, but I think the recipe is roughly:05:04
lifelessbzr branch source_branch clean_branch -r before:first_problem_revision05:05
lifelesscd clean_branch05:05
lifelessbzr nick newnick05:05
lifelessbzr rebase ../source_branch05:05
lifelessand it should take a few minuts05:05
rousskovWhat is source_branch? The private branch I want to clean?05:06
rousskovHm.. Would not before:first_problem_revision simply ignore all the changes on that branch?05:07
lifelessthats the idea05:07
lifelessyou want a branch that starts exactly where your current branch started05:08
lifelessthen you rebase everything from it to the new branch05:08
lifelessas I recall rebase discards the nick as it goes05:08
lifelessbut let me check05:08
rousskovSo, if you are right, "rebase" will bring back all the changes, but not the nick?05:08
lifelessoh damn, it will preserve the nick05:09
lifelessgimme a few minutes, I'll whip up a branch of rebase that won't05:09
rousskovFWIW, there were no revisions on the source_branch before the problem_revision.05:10
lifelessrousskov: oh, I was assuming it was squid05:10
rousskovIt was branched off a public branch (and all the changes should now go back to that branch).05:10
rousskovYou may assume squid, yes.05:11
lifelessso 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 branch05:11
rousskovOK. Understood.05:11
lifelessthis will take a few minutes, my machine is in the middle of a very memory heavy analysis, a little thrashing involved :P05:13
rousskovThank you for taking the time to help me.05:13
lifelessno probs05:14
lifelessnearly there05:33
* rousskov stands by.05:43
lifelessrousskov: I have it working but with a small caveat that is part of the current rebase UI05:50
lifelessrousskov: 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 it05:50
rousskovSure, go ahead05:50
lifelessrousskov: so the caveat is that to rewrite the revisions, rebase wants something *new* in the 'parent' branch its rebasing from.05:50
lifelessthink of rebase as moving all your work out of the way, doing a pull, then one by one replaying them back into your branch05:51
lifelessif there isn't anything to pull it assumes it has no changes to make05:51
lifeless(which in this case is false)05:51
rousskovIt is easy for me to commit to the dirty (or clean) branch. Is that what is required?05:52
lifelessjust a 'bzr commit -m "Prepare xxx branch" --unchanged'05:52
lifelesswill do it05:52
lifeless(don't do it now)05:52
lifelessthe effect is a single revision in the log that is rather meaningless05:52
rousskovOK. At what point in your original process do I do an empty commit?05:53
lifelessI'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 step05:53
rousskovThat is what I call service!05:54
lifelessactually, we may not need that little workaround, found a command I thought existed but couldn't find for a bit :P05:56
lifelesslet me finish these tests05:56
=== k4v is now known as m4v
lifelessrousskov: ok06:14
lifelessmkdir -p ~/.bazaar/plugins06:14
lifelessbzr branch lp:~lifeless/bzr-rebase/dev ~/.bazaar/plugins/rebase06:14
rousskovBranched 115 revision(s).06:15
lifelessidentify the first revision before the revisions you created in the badly nicked branch06:15
lifelesse.g. bzr log06:15
lifelessonce you've found that number:06:16
lifelessbzr branch -r THATNUMBER badly-nicked-branch fresh-branch06:16
lifelesscd fresh-branch06:16
lifelessbzr nick NICKYOUWANT06:16
lifelessbzr replay -r -1 ../badly-nicked-branch06:16
lifelessI have some other things I need to do06:17
lifelessI"ll check back in in 10-15 minutes06:18
rousskovStrange: Text conflict in src/cf.data.pre06:22
rousskovlifeless, I resolved the conflict but running "bzr rebase-continue" yields "bzr: ERROR: No rebase to continue"06:28
rousskovHm. You told me to replay, not rebase, so perhaps that is OK.06:30
rousskovI see many differences between $badly and $fresh so I am guessing replay stopped at some unknown point due to a conflict.06:37
rousskovbzr log in $fresh shows revisions up to and including $THATNUMBER06:42
lifelessrousskov: are you sure you got the right start rev?06:48
lifelessthere shouldn't be any conflicts06:48
rousskovIt was the smallest revision with bad nick minus 106:48
rousskovTHATNUMBER=the smallest revision with bad nick minus 1, based on bzr log in $badly06:49
lifelesslets do rebase then, it could be something odd about replay06:50
lifelessdelete fresh-branch06:50
lifelessbzr branch -r THATNUMBER badly-nicked-branch fake-upstream06:50
lifelessbzr branch badly-nicked-branch fresh-branch06:50
lifelesscd fake-upstream06:50
lifelessbzr commit -m "Prepare DESCRIPTION branch" --unchanged06:50
lifelesscd ../fresh-branch06:50
lifelessbzr rebase --new-nick ../fake-upstream06:51
rousskovWhat is the best way to delete fresh-branch?06:51
lifelessrm -rf06:51
rousskovWould not it remain in the repository?06:52
lifelessrousskov: is that working better?06:56
rousskovI am about to run rebase06:57
rousskovHm. Should I specify nick anywhere?06:58
lifelessin fresh-branch06:58
rousskovSo I can leave it as-is if the $fresh directory name is OK, right?06:59
rousskovIt is committing something06:59
lifelesswell thats a start07:00
rousskovNick appears to be fixed.07:01
lifelessI'm offf for the night then07:01
lifelessjelmer: when you get up - merge request in lp for it07:01
rousskovlifeless, but the result is not the same branch I started with07:03
rousskovI mean, running "diff -ur $badly $fresh" shows many differences in sources.07:03
lifelessthats unusual07:05
lifelesswhat do the changes look like07:05
rousskovIt looks like some of the changes from the trunk were not pulled in07:08
lifelessthats weird07:08
rousskovThe $badly branch was synced with trunk a few times07:08
lifelessjelmer: are you around07:08
lifelessrousskov: I'd like to check a factoid or two with rebase' author07:09
rousskovOK. Thanks for all the help so far.07:09
lifelessI'll chat to jelmer my morning, if you can wait07:11
rousskovI probably have to bail very soon :-(07:11
lifelessand see if this known/expected07:11
rousskovThe missing changes have lower r number than THATNUMBER07:12
lifelessthats extremely odd07:12
rousskovBut they were pulled into the branch later07:12
* rousskov is not explaining well07:12
vilahi all07:13
lifelessif you could drop me a mail perhaps with a little ascii art or something07:13
lifelessI could show it to jelmer (who is european)07:13
lifelessin about 14 hours07:13
vilahey lifeless ! Nice to cross you here !07:13
lifelessvila: hi, I'm just going in fact07:13
vilaI thought so, nice anyway :)07:13
rousskovlifeless, 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
rousskovlifeless, I will send email.07:14
lifelessgotta run07: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
vilaigc: ping ping, still around by chance ?10:51
pooliehey vila11:20
pooliei'm just off myself though11:20
vilahi poolie !11:20
vilapoolie: still there a few minutes^W seconds ?11:21
rockyjelmer: ping11:42
rockyjelmer: just an fyi, the "bzr co" on latest bzr-1.11rc1 and bzr-svn 0.5 branch hangs indefinitely11:44
rockyjelmer: scratch that, false alarm11:51
scodebzr: ERROR: Unknown record type: '\r'14:36
scodeA repo suddenly cannot be bramnched, with that error.14:36
scodeI know it worked a few pushes ago.14:36
scodeThe local repo is fine. All I've ever done with the repo is to push things to it over ssh.14:36
scodeAnyone recognize it? Google found a bug with a similar problem (though a different character for the unknown record type).14:37
james_wscode: can you grab the backtrace out of ~/.bzr.log?14:37
scodeThis is with bzr 1.9 (server) and 1.10 (clien).14:37
james_wwhat was the bug number?14:37
scodejames_w: checking14:37
scodejames_w: 30484814:37
james_wbug 30484814:37
ubottuLaunchpad bug 304848 in bzr ""Unrecognised container format" after push" [High,Incomplete] https://launchpad.net/bugs/30484814:38
scodejames_w: Hold on,w ill find a paste bin for the trace.14:38
scodejames_w: http://paste.lisp.org/display/7363314:40
james_wthis is over ssh?14:40
scodeI 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_wwhat ssh server?14:40
scodejames_w: The branch is local.14:40
scodejames_w: The pushing happened over ssh.14:41
scodejames_w: Branching fails over both http and locally (no ssh)14:41
james_wwhat os did the pushes come from?14:41
scodejames_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
scodeSo the problem only happens when branching from the pushed-to repo.14:42
scodejames_w: And the pused-to repos is in a shared repository btw, without a working copy.14:42
scodejames_w: Server is FreeBSD 7.0-RELEASE, Python 2.5, bzr 1.9.14:42
james_wit looks like something is corrupt14: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_wI'm not sure exactly what though14:43
james_wthe packs or indices it seems14:43
scodejames_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
vadi2How 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 one15:00
Lo-lan-dobzr push --remember $newurl15:01
vadi2thanks :)15:02
=== kiko is now known as kiko-phone
Lo-lan-doIs there a simple way of keeping history linear despite commits done with --local?15:22
Lo-lan-doHm, that wasn't explicit.  I'll rephrase.15:22
jelmerLo-lan-do, bzr rebase --pending-merges15:23
Lo-lan-doAssuming I'm working on a checkout, and for various reasons I do a few commits.15:23
Lo-lan-dojelmer: ♥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
jderemerhello: 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-dojelmer: That's more recent than 0.3, though, right?15:27
jelmerLo-lan-do, yeah, 0.5 I think15:27
Lo-lan-doOkay.  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
rousskovjelmer, 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
jelmerrousskov, yeah, he emailed me about it15:44
jelmerrousskov, rebase doesn't process merges by default15:44
jelmeryou have to specify a separate option for that15:44
rousskov--always-rebase-merges or --pending-merges?15:46
rousskovThank you. I could not guess which one by reading --help output. Pending where? Already present where?15:47
rousskovNever mind, it is just me, I am sure.15:47
* rousskov will retry with --always-rebase-merges15:47
rousskovI hope this will not screw up future bundles when I submit the changes for merging to trunk.15:49
jelmerscrew up in what regard15:49
rousskovLike 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 something15:50
rousskovI do not know the internals of how this works so my questions may make no sense at all.15:51
rousskovIf you tell me "it will work just fine, the option has no bad side effects", I will be happy :-)15:51
jelmeryes, that will happen - that's why rebase is a bad idea in general15:54
rousskovHm. So what is the best option in my case?15:57
rousskovHand-detect missing mergers after running rebase and redo them by hand?15:58
jelmerno, just use --always-rebase-merges15:58
jelmer*any* rebase will break the revision ids15:59
rousskovHow do broken revision IDs manifest themselves in practice?15:59
jelmeryou get divergedbranches errors16:00
rockyjelmer: 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
rousskovjelmer, 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
rousskovAnd it did not help with the missing commits issue either :-(.16:48
rousskovIn other words, I got exactly the same result, except all branch commits have the old nick.16:49
rockstarjam, ping17:28
jamhey rockstar17:28
rockstarjam, still on for TWiB today?17:28
rockstarjam, also, did you see that I replied to that bzr-stats merge proposal from about 6 months ago?  :)17:32
jamrockstar: yeah I saw that, jelmer approved it, did you need me to specifically merge it?17:33
rockstarjam, well, not you specifically, but would like it merge please.17:33
rockstarEr, merged.  English and its tenses...17:34
jelmerI already merged it17:35
=== bac is now known as bac_lunch
rockstarjelmer, hooray!17:42
rockyjelmer: 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
jelmerrocky, yep19:12
=== christoph_ is now known as enigma42
=== thumper_laptop is now known as thumper
dereineis it possible to get a diff of every changed version of a file?21:46
lifelessdereine: all the changes made to a single file?21:47
lifelessyes, but not with a single command21:48
dereineah ok is it possible to see th version when something changed?21:48
lifelesslog FILE will report all the revisions that changed/renamed/merged the file, and bzr diff -r before:rev..rev PATH will givethe diff21:48
beunodereine, and bzr annotate FILE will tell you the last revision that changed each line21:49
lifelessyou may also like 'bzr annotate FILE'21:49
lifelessor 'bzr gannotate FILE'21:49
fullermddiff -crev would be shorter21:49
LarstiQor `bzr qannotate` (or via qbrowse, which is what I usually do)21:49
dereineok i will never ask is it possible21:50
LarstiQdereine: failing that, via bzrlib ;)21:50
dereineLarstiQ: 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 repo21:51
LarstiQdereine: I'm glad you like it :)21:51
dereinei just have to bring other people to use it, i know some people, they don't use any control versioning system21:52
fullermdHey, I know insane people too.21:53
dereinei'm just happy to use bzr local for this project21:53
dereinei have to say, which file i changed21:55
pooliehello all22:05
GaryvdMHi poolie22:07
pooliehello Gary22:08
pickscrapeHow do I get a list of the things on my shelf using the new shelf? (e.g. equivalent of bzr shelf list)22:10
vilabzr shelve --list22:10
vilapickscrape: I think you need 1.11 though22:10
pickscrapeYeah, just discovered that. :(22:10
* pickscrape digs in .bzr/checkout/shelf/22:11
vilawhat ? -- list :-) or you have only 1.10 :-( ?22:11
pickscrapeThat I only have 1.1022:11
vilaWhy don't you upgrade ?22:11
pickscrapeI'm sticking with what the PPA gives me. 1.11 is still in RC isn't it?22:12
pickscrapeThough 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
vilapickscrape: Ok, but I think 1.11final is for today (australian time) though22:13
pickscrapeoh right22:13
pickscrapevila: I'm wrong anyway: it does let you unshelve an arbitrary shelf ID.22:14
vilahere you go...22:14
vilaDon't put too much on your shelve anyway :-)22:15
pickscrapeI 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
pickscrapeI should qualify: when i have to switch branches mid-development.22:16
xokaidohello all...22:41
xokaidois anyone here?...22:42
xokaidohello... :)22:42
fullermdNo.  We left early to get boozed up.22:42
xokaidoI have a little problem in bzr trying to commit my changes using FTP...22:43
xokaidoan SFTP too...22:43
xokaidothe 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
xokaidodoes anyone have idea what to do?..22:44
fullermdThat falls into the category "FTP is too damn weird, and your FTP server is broken"22:44
xokaidofullermd, thx for your reply, but FTP server works just fine...22:44
fullermdWell, no it doesn't.  If it did, the APPE would work   :p22:44
xokaidoit has no problems other then with bzr...22:44
fullermdWhat's the problem over SFTP?22:45
xokaidoit simply can't see the branch...22:45
xokaidoit says there is no branch...22:45
fullermdOh.  How nice of it.22:45
fullermdYou sure it's looking at the right path?22:45
beunoxokaido, sometimes you need to specify the full path over sftp22:45
xokaidoyes, I do...22:45
fullermd(specifically, it will work from / if you don't put a ~ in it)22:45
xokaidobecause with bzr log ftp:// it shows correct log...22:46
beunofullermd, I think bzr doesn't expand ~?22:46
fullermdbzr+ssh doesn't.  sftp deos.22:46
fullermdAnd does, too.22:46
beunoxokaido, did you try both variants?  relative and absolute path?22:46
fullermdxokaido: Try sftp://server/~/[path]22:46
xokaidobeuno, thank you very much, with full path sftp works... :)22:46
xokaidobut how about ftp?...22:46
fullermdFTP is a wonky protocol.  That it ever works is kinda astonishing.22:47
xokaidois there a chance to get it to work?...22:47
beunoxokaido, FTP, as fullermd says, your server is probably "broken"22:47
fullermdThe 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
beunoor "not working as well as it could"22:47
fullermdIf it actually gave a "No, sorry, I don't support APPE", I think bzr would actually work around it.22:47
fullermdBut since it's a temporary failure, we just keep retrying (like it said to), and it never works ('cuz it's broken)22:47
fullermdFor some reason, this is apparently a really common failure with FTP servers.  I don't know why.22:48
xokaidofullermd, thank you very much... can I fix this somehow?...22:48
fullermdNot short of replacing the server software, no.22:48
fullermdBut if SFTP works, it's probably a lot better all around anyway.22:48
jelmerlifeless, awake yet?22:49
xokaidoyes, 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
fullermdWell, since SFTP works here, the FTP case would be on a different server.  So maybe it'll have a different daemon running  ;)22:49
xokaidofullermd, thank you once again for your attention... we hope other FTP server would work better... :)22:50
fullermdIt's probably possible bzr could be hacked to handle that case better.22:51
lifelessjelmer: yes22:54
lifelessjelmer: was just on a call22:55
xokaidoone more problem... :-(22:55
lifelessbeuno: sftp://host/~/ is the same as scp host:22:55
lifelesssftp://host/ is the same as scp host:/22:55
xokaidoam 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
xokaidobut it was the latest... :-(22:56
lifelessxokaido: latest from where?22:57
xokaidofrom bazaar website22:57
xokaidofrom here...22:57
lifelessxokaido: the message may be misleading then, because bzrtools definitely had a 1.6 compatible release; bzr itself is up to 1.10 now22:58
jampoolie: ping22:58
jamJust a quick comment about the new progress bars that you merged22:58
jamIt seems to be nesting things incorrectly22:58
xokaidobzr version shows this: "Bazaar (bzr) 1.6.1"22:58
jamI sent something to the list22:59
lifelessxokaido: yes, and if you got the latest bzrtools, then you will have bzrtools for 1.1022:59
jamBut it seemed like something that you would want to look at directly.22:59
fullermdOr 1.11.22:59
xokaidolifeless, how can I fix this?...22:59
pooliejam: pong22:59
pooliei'll check it out22:59
lifelessxokaido: well, install matching versions23:00
fullermdxokaido: It's got a list of old versions; find the 1.6.x one and grab that.23:00
lifelessxokaido: I don't know how you installed bzr or bzrtools; but 'however you installed them'.23:00
xokaidoyou mean bzr itself or just tools?.23:00
lifelessxokaido: you can either upgrade bzr to a version matching bzrtools, or downgrade bzrtools to a version matching your bzr23:00
xokaidohow do I upgrade bzr?... is there bzr checkout ?23:01
GaryvdMxokaido: how did you install bzr?23:01
xokaidoGaryvdM, from slackware package...23:02
xokaidoI downloaded it from bzr website...23:02
xokaidoI have experience neither in svn nor in cvs... :-(23:02
xokaidobut bzr seems to be the coolest thing...23:03
jelmerlifeless, so, stacked branches rely on versionedfiles very much at the moment23:03
xokaidoI could quickly understand what's going on...23:03
jelmerlifeless: 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
GaryvdMxokaido: Not sure who did that package. Need to nudge them to update it.23:04
xokaidoGaryvdM, I'll try to reinstall it using sources...23:05
lifelessjelmer: indeed it would23:07
lifelessjelmer: did you see my query about rebase23:07
jelmerlifeless, I did see it and chatted with him here on IRC a bit23:11
xokaidoGaryvdM, thank you very much... it works now just fine... :-)23:12
lifelessthe special thing seems to be that the merges were of branches from the same branch point23:12
lifelessI'm wondering if there is an off-by-one error in there somewhere23:12
jelmerlifeless: could be, I think there's another open bug about this23:14
lifelesswhere in the code is the 'I should skip a rev' logic23:14
lifelessjelmer: also was the patch ok23:15
jelmerlifeless: generate_simple_plan()23:15
LarstiQoh that's precious23:16
xokaidowow, the coolest plugin is the 'shell' command in bzr.... much thanks to the author... :-)23:19
lifelessLarstiQ: whats precious23:19
* xokaido says: thank you guys all... 23:20
LarstiQlifeless: it seems it is already reported as https://bugs.edge.launchpad.net/bzr/+bug/8255523:22
ubottuLaunchpad bug 82555 in bzr "Merging to an empty branch doesn't work" [Medium,Confirmed]23:22
LarstiQlifeless: merging into an empty branch. bzr log of all of it shows me one revision, with revno 5 in this case.23:23
lifelessbranch version?23:24
LarstiQlifeless: Branch format 6, if that is what you're asking23:27
LarstiQI was trying to reproduce a bug where the revnos would go into the negatives23:27
LarstiQbut either I forgot how to do that, or it has since been fixed23:27
LarstiQor well, bugs differently23:27
mwhudsonoh that's interesting23:28
mwhudsoni've seen borked branches in a state like that23:28
rousskovlifeless, 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
rousskovI 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
rousskovlifeless, 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
LarstiQI'd assume the nick is included in all the hashes etc23:53
rousskovDoes not look like it.23:53
rousskovThe edited bundle applies cleanly.23:53
LarstiQdoes it also apply that nick?23:53
rousskovbzr bundle-info works, etc.23:53
rousskovNo. That's the problem.23:53
LarstiQyou edited in the for-human text part, or in the encoded machine readable part?23:53
rousskovThe theory is that the repository already saw those revisions so it just skips them.23:54
james_wthe nick is stored in the revision23:54
LarstiQAh, or that.23:54
rousskovI edited the machine readable part.23:54
LarstiQrousskov: so yeah, then you'd effectively be creating more than one content for a given revision, thereby violating an important invariant23:54
LarstiQrousskov: ok23:54
lifelessrousskov: 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 ame23:55
rousskovbut what if I do not care about the revision with the old nick? I am willing to dump/delete it.23:55
lifelesssecondly folk ask for this sort of history edit from time to time; I think its important to have a simple slick answer23:55
LarstiQfair enough23:56
LarstiQrousskov: 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
lifelessLarstiQ: the revision contents are fine23:56
rousskovI would love a simple slick answer as long as it is not a "no, you should have thought about it earlier"23:56
lifelessrousskov: clearly thats not an answer23:57
rousskovnot yet :-)23:57
sevenseekercan I use bzr-svn on an existing svn workingcopy?23:57
rousskovLarstiQ, So you recommend a) generating a bundle b) removing old revisions c) applying the edited bundle?23:58
lifelessrousskov: so, --always-rebase-merges is needed23:58
jelmersevenseeker, yes23:58
lifelessrousskov: I think its a bug that its needed, because bzr has enough info to tell that the merge is needed23:58
lifelessjelmer: ^ for discussion23:58
lifelessrousskov: what happened when you tried with --always-rebase-merges --new-nick ?23:58
LarstiQrousskov: I hesitate to recommend things, I don't have enough information and wouldn't like to irrevocably destroy your data.23:58
rousskovI got old nick and same missing revisions.23:59
* LarstiQ trusts lifeless to help rousskov out.23:59
rousskovLarstiQ, post your lawyer's address just in case anyway.23:59
LarstiQit being almost 01:00, it's waaay past my bedtime anyway.23:59
LarstiQrousskov: :)23:59
lifelessjelmer: ping, can we spend some time on this23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!