| lifeless | wow I love this plugin shit man | 00:15 |
|---|---|---|
| lifeless | someone just added a plugin to do regex based mass renaming | 00:16 |
| chx | oooh | 00:16 |
| chx | so if i created a repository without rich roots (--1.9 ) then i cant change it now? | 00:17 |
| lifeless | chx: you can upgrade to a rich roots flavour if you need to, but unless you have a specific need to don't. | 00:17 |
| lifeless | we'll make a big noise and give instructions etc to everyone when we're ready to make rich roots the default | 00:18 |
| chx | lifeless: ok. | 00:18 |
| lifeless | spiv: ping | 00:19 |
| edcrypt_ | lifeless: this someone is me (the multi-renaming plugin) :) | 00:20 |
| lifeless | edcrypt_: cool! | 00:20 |
| mwhudson | argh | 00:21 |
| mwhudson | getting BzrCheckError: Internal check failed: Newly created pack file <bzrlib.repofmt.pack_repo.NewPack object at 0x21bb410> has delta references to items not in its repository: ... pusing to launchpad | 00:21 |
| mwhudson | do i need to reconcile the branch? | 00:21 |
| chx | lifeless: if you would take time to read http://drupal.org/node/289117 and offer your view on some of the relevant points, i'd be delighted. I wanted Drupal on bzr for long and now David Strauss is partner in crime :) and also bzr got a tortoise -like Windows interface and also it became a lot faster so we are getting there | 00:21 |
| edcrypt_ | lifeless: its my first plugin, I hope its not the code is not too horrible | 00:22 |
| lifeless | chx: I have a hectic day today, so I can't make any promises, but I'll see what I can do | 00:23 |
| chx | I could find no documetnation of that Windows integration since it became integrated into bzr -- or the http://bazaar-vcs.org/TortoiseBzr page is still relevant despite it's shipped with bzr since 1.6? | 00:23 |
| === davidstrauss_ is now known as davidstrauss | ||
| mwhudson | oh god that "Brief article on benchmarks of Python repository with leading DVCSen" thread is so long | 00:39 |
| lifeless | mwhudson: short story long analysis | 00:40 |
| * mwhudson hits r and moves on | 00:40 | |
| rysiek|pl | ah, well | 00:40 |
| * rysiek|pl 'll finish removing cruft tomorrow | 00:41 | |
| rysiek|pl | thanks a lot for your help, guys | 00:41 |
| rysiek|pl | cu | 00:41 |
| lifeless | ciao | 00:41 |
| === Daviey_ is now known as Daviey | ||
| lamby | jelmer: I was wondering whether you could remove me from the Uploaders in bzr-gtk? Alas I haven't run bzr since I last played with that package in May '08. | 01:49 |
| jelmer | lamby, sure, np | 01:49 |
| lamby | I would do it myself but my non-DD alioth account (with the right perms) is gone. | 01:50 |
| lamby | Was pleasure working with you, hopefully we'll cross paths (both technically and personally) soon. | 01:50 |
| lamby | Take care and good night. | 01:50 |
| jfroy | mwhudson: where is that thread you spoke of? Sounds interesting | 02:09 |
| * igc back from doctors | 02:12 | |
| lifeless | jfroy: last week, about 40% of the traffic on bazaar@ | 02:12 |
| jfroy | lifeless: thanks! | 02:14 |
| jfroy | Just read the PDF, and although it's very slim on experimental procedures, the data is a little bit harsh on bzr >.> | 02:25 |
| jfroy | (now reading the mailing list thread) | 02:25 |
| jml | uhh | 02:37 |
| lifeless | huu | 02:37 |
| jml | I'm starting to get a *lot* of email about ~launchpad-pqm/bzr/dev | 02:38 |
| lifeless | I shall return shortly, getting bottled caffeine and other essentials | 02:38 |
| jml | oh wait, that's *our* branch of bzr. | 02:38 |
| jfroy | *phew* that was a long thread. | 03:16 |
| === UdontKnow is now known as ObiWanQueNoob | ||
| * igc picks up kids | 04:49 | |
| gotgenes | I tried to do a Daggy Fix per http://monotone.ca/wiki/DaggyFixes/, which is linked off of http://bazaar-vcs.org/CherryPick, but it did not work at all like I expected. I must be missing something. | 04:53 |
| === ObiWanQueNoob is now known as UdontKnow | ||
| gotgenes | I introduced a bug at revision 77 of the trunk, which is now at 90-something. | 04:54 |
| gotgenes | I made a branch from revision 77, fixed the bug, and committed to the branch. | 04:54 |
| gotgenes | Then I attempted a merge from the bugfix branch to the trunk. It resulted in a conflict because of all the revisions in the trunk since revision 77. | 04:56 |
| lifeless | gotgenes: this is one of the big flaws with daggyfixes | 05:02 |
| gotgenes | lifeless: shoot | 05:02 |
| gotgenes | So I didn't necessarily do it wrong, right? | 05:02 |
| gotgenes | Was I supposed to select a revision range from the bugfix branch instead? Does that still cause the cherry-picking problem? | 05:03 |
| lifeless | gotgenes: you haven't cherry picked at all | 05:03 |
| gotgenes | lifeless: right, I was trying to avoid cherry-picking | 05:03 |
| lifeless | gotgenes: daggy fixes doesn't rely on cherry picks, but it leads to conflicts where the code has been changed since the bug was introduced | 05:04 |
| gotgenes | since it says "it creates intransitive branches" | 05:04 |
| lifeless | well | 05:04 |
| gotgenes | er, ancestors | 05:04 |
| lifeless | I don't do daggy fixes, I think they rarely work well in code that is being looked after, so I'm not really well positioned to tell you how to make it work | 05:04 |
| gotgenes | lifeless: How do you merge in bugfixes to multiple releases, then? | 05:05 |
| lifeless | I cherrypick | 05:06 |
| lifeless | if we introduce a bug in say 1.6 | 05:06 |
| lifeless | and fix it during the 1.11 cycle | 05:06 |
| lifeless | we generally don't merge it to multiple releases at all | 05:06 |
| lifeless | but if we need to, we'd cherry picked it from the 1.11 branch | 05:06 |
| lifeless | with one release a month, there is a massive cost to cherrypicking every bugfix across multiple releases | 05:07 |
| lifeless | because there are lots of releases :) | 05:07 |
| gotgenes | Yeah. | 05:08 |
| gotgenes | I can see that. | 05:08 |
| gotgenes | What about "cherry picking" the other way, as a forward port? | 05:09 |
| lifeless | if we released every six months it would be different | 05:09 |
| lifeless | so, cherry picking forward is daggy fixes | 05:10 |
| gotgenes | Is it? | 05:10 |
| lifeless | just starting sometime after the bug rather than 'right on' | 05:10 |
| gotgenes | so technically branches after it should have all necessary ancestors, correct? | 05:10 |
| lifeless | yeah, you would not need to cherry pick to go from 1.10 to 1.11, its a simple merge | 05:10 |
| lifeless | but the issues are the same: code that has been maintained will have skewed, as you experienced | 05:11 |
| gotgenes | yeah, I made a lot of edits on this file between revision 77 and now | 05:11 |
| lifeless | yup | 05:11 |
| gotgenes | but the lines I patched--they've been the same since | 05:12 |
| lifeless | gotgenes: well, you could try --weave-merge and see if that behaves better for you | 05:12 |
| gotgenes | so the revision 77-78 patch in the bugfix branch is what I need to put in my release branches | 05:12 |
| gotgenes | lifeless: that's a good idea | 05:12 |
| lifeless | I'm starting to think we need to revisit using patience diff | 05:12 |
| gotgenes | what's a patience diff? | 05:13 |
| * gotgenes should google it | 05:13 | |
| lifeless | its a clever diff algorithim thought up by the codeville authors | 05:13 |
| lifeless | but it depends very heavily on ordering of unique lines | 05:13 |
| lifeless | and I'm starting to think its too easy to break it badly | 05:13 |
| gotgenes | so in my case, at commit 91, a lot of lines are unique to that commit compared to 77, so that throws off the algorithm? | 05:15 |
| lifeless | gotgenes: uhm, I don't know it well enough to boil it down to a straight forward yes or no | 05:16 |
| lifeless | but I can point you at the code :) | 05:16 |
| gotgenes | So I did --weave and it didn't complain, says the file friendfeed.py was modified, but bzr diff friendfeed.py doesn't actually reveal what changed, and bzr status doesn't list the file as modified, but lists it in "pending merges" | 05:16 |
| lifeless | gotgenes: *blink* if this is open source please file a bug | 05:17 |
| lifeless | thats clearly bogus | 05:17 |
| gotgenes | lifeless: My project is definitely open source | 05:17 |
| lifeless | cool | 05:17 |
| gotgenes | https://code.launchpad.net/~chris.lasher/friendfeed-pyapi/0.1.0/+merges | 05:18 |
| gotgenes | That's what I'm trying to do at the moment. | 05:18 |
| gotgenes | blarg, how do you back out of a merge? | 05:29 |
| * igc back | 05:31 | |
| gotgenes | ah, mark conflicts as resolved first, then revert | 05:32 |
| stub | Is there a plugin somewhere that implements upgrade-repo ? Or is standard practice to throw together a shell script to upgrade the repo and all its branches? | 05:36 |
| lifeless | gotgenes: 'bzr revert' should just work | 05:40 |
| lifeless | gotgenes: don't do 'bzr revert .' because that doesn't back out the merge | 05:40 |
| gotgenes | lifeless: ah, that's the trick | 05:41 |
| gotgenes | I was using '.' | 05:41 |
| lifeless | why? | 05:41 |
| gotgenes | um | 05:42 |
| gotgenes | habit? | 05:42 |
| lifeless | yeah, but from where? | 05:42 |
| gotgenes | svn maybe? | 05:42 |
| lifeless | no bzr commands need '.' :P | 05:42 |
| gotgenes | silly me | 05:42 |
| lifeless | 'bzr revert .' says 'revert only the subtree, no metadata' | 05:42 |
| gotgenes | so explicit, too | 05:43 |
| gotgenes | lesson learned | 05:43 |
| gotgenes | Thanks for your patience. | 05:43 |
| lifeless | my pleasure | 05:43 |
| gotgenes | I do really enjoy bzr | 05:43 |
| gotgenes | the Launchpad integration's a thing of delight for me, too. | 05:44 |
| lifeless | excellent | 05:44 |
| gotgenes | A couple of us in the BioPython project are trying to push it to bzr. | 05:44 |
| gotgenes | There's the classic batting-around of the big 3 at the moment. | 05:44 |
| lifeless | oh, I'm sure there is :) | 05:50 |
| ronny | lifeless: is there any way to merge only a subtree of the full trr within a repo, it would be helpfull for stuff like wiki's where the granularity tends to be page-based, not tree based | 06:29 |
| lifeless | ronny: bzr merge branch/subtree && bzr commit | 06:41 |
| lifeless | ok, I'm done for the day; ciao | 06:41 |
| ronny | hm | 06:41 |
| ronny | now i have to figure an api for that | 06:42 |
| vila | hi all | 07:41 |
| thumper | hi vila | 08:04 |
| thumper | vila: what are you up to today? | 08:04 |
| vila | hi thumper | 08:04 |
| vila | cleaning my plate of minor issues and fixing tests in brisbane-core, need any help on something ? | 08:05 |
| ronny | are there any docs on the structure of brisbane-core? | 08:06 |
| vila | ronny: that's a pretty vague question :-/ I don't think there are any high-level easy to grasp doc by itself... There have been many discussions on the mailing list, many intermediate result reports but I'm not sure you will call that doc | 08:08 |
| ronny | sad | 08:09 |
| thumper | help | 08:10 |
| thumper | bzr: ERROR: The dirstate file (DirState(u'/home/tim/src/lp/rocketfuel-devel/.bzr/checkout/dirstate')) appears to be corrupt: | 08:10 |
| thumper | just from a measly Ctrl-C | 08:10 |
| thumper | can I fix it? | 08:10 |
| thumper | or shall I just blow the checkout away and get another one? | 08:10 |
| * thumper re-checkingout | 08:12 | |
| vila | thumper: better blow the checkout away I'm afraid :-/ We should really have some command to re-create a dirstate from scratch though | 08:12 |
| vila | thumper: if it's not too late may be filing a bug and attach the dirstate file, there may be some simple fix to avoid most common causes (no matter how rare they are, and they appear to be very rare to the best of my knowledge) | 08:14 |
| thumper | vila: I kept a copy of the checkout | 08:15 |
| thumper | vila: so I could file something later | 08:15 |
| thumper | vila: but I'm chasing an issue right now | 08:15 |
| vila | thumper: fair enough, I make no promises either but we have to start somewhere (and I fully understand 'chasing an issue right now' :-) | 08:16 |
| thumper | :) | 08:17 |
| vila | thumper: just for curiosity, was the ctrl-C misplaced or caused by a fear about not being able to reverse the command effect ? | 08:17 |
| lifeless | thumper: ctrl-C is odd, because we write to a different file, then rename | 08:18 |
| lifeless | *I thought* | 08:18 |
| * thumper shrugs | 08:21 | |
| * igc1 dinner | 08:43 | |
| === weigon__ is now known as weigon | ||
| ronny | how does bzr store tags? | 09:20 |
| Peng_ | What do you mean? | 09:28 |
| ronny | Peng_: how does it store tags for a revision | 09:30 |
| ronny | oh, i just found the store | 09:31 |
| ronny | hmm | 09:32 |
| ronny | jelmer: any reason why tags are storend like [<len>:<name><len>:<rev>]* | 09:33 |
| Peng_ | Are they bencoded? | 09:34 |
| ronny | the numbers are ascii text | 09:35 |
| Peng_ | Yeah, it looks like .bzr/branch/tags is bencoded. I never noticed that before. | 09:40 |
| ronny | lifeless: if i merge a subdir of a branch it stops being able to merge the rest later | 09:42 |
| Youssef | Hello all | 09:43 |
| Youssef | or good morning for belgian people | 09:43 |
| Youssef | i have a question! | 09:43 |
| Youssef | who can help me? | 09:44 |
| ronny | lifeless: odd, now it works again | 09:44 |
| Lo-lan-do | Youssef: Nobody until you've asked. | 09:44 |
| Youssef | :) | 09:45 |
| Youssef | soo | 09:45 |
| Youssef | so | 09:45 |
| Youssef | i would like to lock a file woth bazaar like we do in subversion | 09:45 |
| Youssef | is it possible first? | 09:45 |
| Youssef | "with" bazaar sorry | 09:46 |
| Youssef | not woth | 09:46 |
| Peng_ | Youssef: No. | 09:46 |
| mvo | hm, I have a update-manager branch (not-automatic) that bzr 1.6.1 merges happily into the "main" branch. but 1.9 (and 1.11) from jaunty say "Nothing to do". did something n the (default) merge algo change? | 09:50 |
| mvo | ("not-automatic" is the name of the branch) | 10:01 |
| ronny | lifeless: how does bzr manage metadata about subdir merges? im taking a look at bzr vis, but there it looks like a normal revision | 10:03 |
| Youssef | Peng! | 10:04 |
| Youssef | what it's not possible to lock in bazaar? | 10:05 |
| ronny | Youssef: hu? | 10:05 |
| Lo-lan-do | How could you lock in a DVCS? | 10:06 |
| alex_morelli | hi all | 10:10 |
| alex_morelli | how do I move a branch from a shared repo to another? | 10:11 |
| Lo-lan-do | alex_morelli: Branch from one to the other, then remove it from the original one? | 10:11 |
| alex_morelli | Lo-lan-do: What makes me hesitate is that I have two shared repos without trees and I would like to move (or copy) a branch from the first to the second | 10:12 |
| Peng_ | alex_morelli: So? | 10:13 |
| Lo-lan-do | "bzr branch", also known as "bzr clone", is exactly a branch copy, whether for shared repos or not. | 10:13 |
| alex_morelli | I tried to do this: | 10:13 |
| alex_morelli | bzr init-repo --no-trees /opt/new-repo | 10:14 |
| alex_morelli | cd /opt/new-repo | 10:14 |
| alex_morelli | bzr branch /<other-repo>/project | 10:14 |
| alex_morelli | now, do I feel like the complete idiot.... I was checking out, not branching | 10:16 |
| alex_morelli | thanks everybody... | 10:16 |
| Peng_ | At least it was easy to solve. :) | 10:17 |
| Peng_ | Explaining problems often helps you figure them out. | 10:17 |
| beuno | we should enforce lag | 10:18 |
| Lo-lan-do | bzr status enforces a 1-second lag on me already. | 10:19 |
| * awilkins wonders where the win32 builds of 1.12 are | 10:26 | |
| * Lo-lan-do wonders where the lenny backports of 1.12 are | 10:27 | |
| Lo-lan-do | ;-) | 10:28 |
| awilkins | Bah, at least you can build it easily enough on Lenny | 10:28 |
| awilkins | Building it on win32 is a female dog | 10:29 |
| === mark1 is now known as markh | ||
| Youssef | guys please | 10:47 |
| Youssef | noone respond me | 10:47 |
| Youssef | is it possible to do a lock to a fille with bazaar? | 10:47 |
| Lo-lan-do | Yes we did. | 10:48 |
| stub | He wants to lock a file in his branch or repository, not every branch or repository. | 10:55 |
| stub | I don't think it is possible to do that in bzr like in svn (not that I've ever done it in svn). There are better ways of working with a DVCS. | 10:56 |
| ronny | Youssef: why do you need that lock | 10:57 |
| Youssef | becoz my want it | 10:58 |
| Youssef | heheh dunno why | 10:58 |
| Youssef | mayber sick!? dunno. | 10:58 |
| Youssef | maybe | 10:58 |
| Youssef | :p | 10:58 |
| stub | Locks are useful for files that can't be merged sanely. You want to flag that you are the person messing with it, and nobody should touch it until you have committed. | 11:01 |
| stub | I don't think this can be done sanely with bzr or any DVCS. | 11:02 |
| ronny | jelmer: ping? | 11:31 |
| markh | awilkins: things like that are always subjective - I find building bzr on Windows quite simple these days :) | 11:39 |
| ronny | hmm | 11:40 |
| ronny | is there any reason why bzr branch in a repo wont create a workdir, even if the branch thats getting branched has one? | 11:41 |
| Odd_Bloke | ronny: If the repository was created with --no-trees. | 11:42 |
| ronny | ah, i see | 11:42 |
| ronny | cna that be reconfigured? | 11:43 |
| Odd_Bloke | ronny: Yes, but not using a bzr command AFAIK. | 11:43 |
| ronny | rm .bzr/repository/no-working-trees ? | 11:44 |
| Odd_Bloke | I think the code looks for a .bzr/repository/no-working-trees in the... yes. | 11:44 |
| Odd_Bloke | :) | 11:44 |
| ronny | hmm | 11:44 |
| ronny | anyone awae how bzr tracks partial merges? | 11:45 |
| ronny | unforutnately there isnt a tool to view the history of specific trees so its tricky to figure | 11:45 |
| ronny | oh dammit | 11:46 |
| ronny | actually partial merges can produce merge conflicts later | 11:46 |
| ronny | lifeless: its kinda useless if it doesnt fix conflicts | 11:46 |
| ronny | its just no fun having to fix conflicts twice | 11:47 |
| fullermd | It doesn't. | 11:52 |
| fullermd | Cherrypicks aren't tracked, whether they're of disconnected sections of history, or of partial bits of the tree. | 11:53 |
| ronny | sad | 11:54 |
| ronny | then its useless for me | 11:54 |
| fullermd | No different from any other major tree-oriented system. | 11:55 |
| fullermd | You can't record "I've merged this revision", since you haven't; you've only taken some changes from it. | 11:56 |
| fullermd | It probably works in svn, since it's not tree-oriented. | 11:56 |
| fullermd | You could do a full merge, and then revert everything but that subdir. That would record it. | 11:56 |
| fullermd | But of course, since you recorded that you've merged those revs, you'll never get changes to the other files in the future. And probably set up some ugly conflicts there later. | 11:57 |
| ronny | cant it be recorded at least for the tree | 11:58 |
| ronny | else its just generating merge conflicts and pretty useless | 11:59 |
| fullermd | But what could you record? | 11:59 |
| ronny | no idea, doesnt each tree have a parent? | 12:00 |
| fullermd | Merges are recorded by tieing revisions into the ancestry. | 12:00 |
| fullermd | They're not recorded by saying "Oh, I got change X to file Y from over here". | 12:00 |
| fullermd | The tracking happens by merge later saying "Oh, I've already got this revision, so I don't need to look at it again". | 12:01 |
| ronny | cant it do that with trees, too? | 12:01 |
| fullermd | By having a non-tree-oriented system, like svn. Or by inventing a whole new layer of metadata, which would be a rich field for bugs, and probably very touchy. | 12:02 |
| fullermd | I mean, anything _can_ be done. | 12:03 |
| fullermd | But it's far more likely that some solution will be created for tracking the cherrypicking of revisions, long before cherrypicking of PARTS of revisions. | 12:03 |
| fullermd | And that's an ugly enough problem in itself. | 12:03 |
| ronny | hmm | 12:08 |
| fullermd | (actually, I'm not even sure it svn can record merges of parts of revisions and DTRT.) | 12:09 |
| fullermd | But I would guess it does, or at least can relatively easily. | 12:10 |
| fullermd | As well as it DTRT with anything, of course ;) | 12:10 |
| awilkins | markh: Yes, it's getting the environment up that's the nasty bit :-) it's very easy after that | 12:30 |
| verterok | vila: I'm back home, dmg for 10.4 is comming ;) | 12:49 |
| vila | verterok: great ! | 12:49 |
| verterok | vila: oh, Hi :) | 12:49 |
| LeoNerd | Anyone have a nice bash trick on how to ignore .bzr directory for tab complete? | 12:50 |
| * fullermd points at the manpage and the first match for /dot | 12:52 | |
| fullermd | And then smack yourself (or whoever you stole your rc file from) for setting the option in the first place :p | 12:53 |
| CBro2007_ | hi I am new to BZR | 14:14 |
| CBro2007_ | any users here? | 14:14 |
| CBro2007_ | just had a few questions about it | 14:14 |
| CBro2007_ | I have just created some files under revision control | 14:14 |
| CBro2007_ | now I was wondering how I can "checkout" revisions from the past? | 14:15 |
| CBro2007_ | like an undo feature? | 14:15 |
| Odd_Bloke | CBro2007_: Look at 'bzr revert'. | 14:16 |
| CBro2007_ | ok | 14:16 |
| weigon | revert, uncommit or just branch to a older revision | 14:17 |
| Odd_Bloke | CBro2007_: Or possibly uncommit, depending on whether you want to revert content or commits. | 14:17 |
| CBro2007_ | I am super new... just looked at it 5 mins ago | 14:17 |
| CBro2007_ | and just trying to see if it will work for me | 14:17 |
| CBro2007_ | so now that I have created a repository.... this will keep the history of the project? | 14:18 |
| === serg is now known as serg|away | ||
| CBro2007_ | is that what I should have in my .bzr directory? | 14:18 |
| LeoNerd | fullermd: I already have dotglob off | 14:18 |
| LeoNerd | fullermd: this means that .bzr isn't listed if I do echo * | 14:18 |
| LeoNerd | That doesn't affect the tab complete; complete 0-f | 14:19 |
| LeoNerd | -f | 14:19 |
| asabil | CBro2007_: bzr init hello && cd hello && touch hello-world && bzr add hello-world && bzr commit -m "Initial import" | 14:19 |
| asabil | that's the complete sequence for a really quick start | 14:19 |
| CBro2007_ | I have done all that | 14:20 |
| CBro2007_ | but one step at a time | 14:20 |
| asabil | yep, then that's all what you really need to start hacking | 14:21 |
| CBro2007_ | I am just trying to understand what my WORKING copy is and if I screw something up how I can revert back to a good copy? | 14:21 |
| asabil | bzr revert -r -1 | 14:21 |
| asabil | to return to the previous commit | 14:21 |
| asabil | (sort of) | 14:21 |
| ronny | hmm | 14:21 |
| ronny | still no support for update -r ? | 14:22 |
| asabil | I also suggest installing bzr-gtk or qbzr to view the history | 14:22 |
| === UdontKnow is now known as ObiWanQueNoob | ||
| asabil | ronny: https://bugs.launchpad.net/bzr/+bug/45719 | 14:24 |
| ubottu | Ubuntu bug 45719 in bzr "update command cannot take a revision number" [Medium,In progress] | 14:24 |
| ronny | ah, nice | 14:24 |
| asabil | CBro2007_: another better solution imho is to use bzr branch | 14:26 |
| asabil | bzr branch -r 1234 trunk old-trunk | 14:26 |
| ronny | oh, not so nice, seems kinda dead | 14:27 |
| ronny | asabil: branch sucks in various cases when going back in history | 14:28 |
| asabil | personally I prefer this approach, since I tend to maintain multiple "builds" | 14:28 |
| asabil | but different people have different workflows | 14:28 |
| stefanlsd | Anyone seen this before - bzr: ERROR: exceptions.TypeError: run() got an unexpected keyword argument 'verbose' (doing an bzr status) | 14:42 |
| jelmer | stefanlsd, out of date bzr-loom I think | 14:43 |
| fullermd | LeoNerd: Well, I dunno. I don't use bash (actually, had to think for a second to figure out which boxes even had it installed) | 14:44 |
| fullermd | LeoNerd: A little more /-ery finds match-hidden-files though. | 14:45 |
| LeoNerd | Oooh | 14:45 |
| fullermd | (though the description doesn't make a damn bit of sense.) | 14:45 |
| stefanlsd | jelmer: thanks. thats prob it. will update it from the ppa | 14:45 |
| jelmer | stefanlsd, afaik bzr-loom isn't in the ppa | 14:45 |
| LeoNerd | Excellent. That has it | 14:45 |
| LeoNerd | Thanks. | 14:46 |
| * fullermd just assumes the option name makes more sense than the alleged explanation ;p | 14:46 | |
| LeoNerd | Now all I have to do is work out how to have it ignore 'CVS' :) | 14:47 |
| fullermd | Oh, that's what "rm" is for ;) | 14:47 |
| quicksilver | grah! | 14:51 |
| quicksilver | I can never find loggerhead's "real" home page | 14:51 |
| quicksilver | https://launchpad.net/loggerhead | 14:51 |
| quicksilver | ^^ is that the right one? | 14:51 |
| * fullermd didn't know our patches were tracked by Brigitte Bardot. | 14:59 | |
| fullermd | No wonder bzr is so awesome... | 15:00 |
| vila | fullermd: :) | 15:04 |
| vila | quicksilver: 'bzr lp-open lp:loggerhead' goes straight to the trunk branch, from there you can click the Overview tab :) | 15:05 |
| quicksilver | ;) | 15:07 |
| quicksilver | vila: google search for 'loggerhead bzr' fails | 15:07 |
| quicksilver | which is a bit odd. | 15:08 |
| vila | quicksilver: file a bug against google :) | 15:08 |
| Odd_Bloke | Sounds more like a Launchpad SEO problem. :) | 15:09 |
| vila | speaking of google and bzr, does anyone know hw to add search engines python, I added some (for modules, documentation, mailing list and bugs) but I can't remember where I found them :-/ | 15:12 |
| vila | gee, s/garbage/how to add search engines for python/ | 15:12 |
| vila | add search engines to *Firefox*, looks like I really don't want to help people who can answer :) | 15:14 |
| === kiko-zzz is now known as kiko | ||
| CBro2007_ | guys I just created the "initial import" | 15:30 |
| CBro2007_ | I want to be able to create a fresh copy of my project so I can start adding new features to it | 15:30 |
| CBro2007_ | how do I do this in Bazaar? | 15:30 |
| CBro2007_ | should I be making the changes to my working copy now? | 15:30 |
| CBro2007_ | or do I create a new branch from my initial import? | 15:31 |
| CBro2007_ | just trying to understand how I can structure this | 15:31 |
| CBro2007_ | anyone got any suggestions? | 15:33 |
| Lo-lan-do | You can work in the same place, or create another branch. | 15:33 |
| awilkins | bzr init-repo /home/me/my-new-repo --no-trees ; bzr push ~/my-new-repo/my-project/trunk --create-prefix ; bzr push ~/my-new-repo/my-project/feature-1 ; bzr bind ~/my-new-repo/my-project/feature-1 | 15:42 |
| === cprov is now known as cprov-lunch | ||
| evarlast | i think I may have had a file once in the history of my bzr branch. I would like to find the said file. does bzr have a find command? bzr find -r 1.. FileName*.c ? | 15:57 |
| fullermd | log -v | grep? | 15:58 |
| evarlast | ah, duh. thanksyou. | 15:58 |
| Youssef | thanks all | 16:18 |
| Youssef | i have to go bye | 16:18 |
| Youssef | ++ | 16:18 |
| jelmer | verterok, ping | 16:26 |
| === ObiWanQueNoob is now known as WHATEVER | ||
| vila | spiv_: go back to sleep :) | 16:45 |
| vila | jam: ping | 16:47 |
| vila | jam: in bbc, do we intend to keep development3 or can I delete it ? | 16:49 |
| jam | vila: I'm deleting it as part of my --development5 patch | 16:49 |
| jam | so I wouldn't delete it *just* yet | 16:49 |
| jam | further, I'm technically on holiday today... | 16:49 |
| vila | jam: oh sorry | 16:49 |
| jam | its fine | 16:49 |
| jam | I'm building the 1.12 installers | 16:49 |
| jam | and doing other work | 16:50 |
| jam | and certainly, lurking on IRC :) | 16:50 |
| vila | True holiday :) | 16:50 |
| * vila notes to never go in vacations with jam :-P | 16:50 | |
| jam | well, I do take real vacations | 16:50 |
| jam | but only when my wife is *also* on vacation | 16:51 |
| jam | today is a federal holiday | 16:51 |
| jam | so it is a Canonical holiday | 16:51 |
| jam | but it isn't a holiday all businesses recognize | 16:51 |
| vila | haaa, that kind of holiday :) | 16:51 |
| jam | so I'm mostly using it as a day to play with stuff | 16:52 |
| jam | like finally setting up the new Ubuntu based server w/ 1TB RAID1 drives | 16:52 |
| vila | SSD ? | 16:53 |
| jam | (as opposed to my old FC3/4 server) | 16:53 |
| jam | well, new as in 3+ years old | 16:53 |
| jam | but better than my 10-year old server I have now | 16:53 |
| jam | :) | 16:53 |
| jam | the hard-drives are new | 16:53 |
| vila | good enough :) | 16:53 |
| jam | It seems that Ubuntu install disks don't like to do software raid by default | 16:53 |
| jam | it seems that the "server" version might be a bit better | 16:54 |
| jam | but instead you can use the live cd | 16:54 |
| jam | to configure everything manually | 16:54 |
| jam | and then install | 16:54 |
| jam | but it took 2 different guids | 16:54 |
| jam | because one didn't explain the simple "you should have used -server" fact | 16:54 |
| jam | and the other assumed you didn't, but was setting up raid 10 rather than just raid 1 | 16:54 |
| Mez | what does | 16:54 |
| Mez | Value "bzr+ssh://io/home/bzr/mf/lib/branches/foo/" is masked by "bzr+ssh://io/home/bzr/mf/lib/branches/foo" from locations.conf | 16:54 |
| Mez | mean? | 16:54 |
| jam | Mez: you have a value in ~/.bazaar/locations.conf | 16:55 |
| jam | and a value in .bzr/branch/branch.conf | 16:55 |
| jam | the value in locations.conf "wins" | 16:55 |
| jam | but may not be what you actually want | 16:55 |
| jam | most likely you did "XXX --remember" | 16:55 |
| Mez | this is a new branch though | 16:55 |
| jam | Mez: then I would guess you have a recursive policy set in locations.conf | 16:56 |
| jelmer | Mez, perhaps an older branch existed on the same location? | 16:56 |
| Mez | new repo. | 16:56 |
| Mez | Maybe it's being bound automatically on first push ? | 16:56 |
| verterok | jelmer: pong | 16:57 |
| jelmer | verterok, does the main bzr dmg include bzr-svn these days? | 16:57 |
| Mez | hwo cna I check if a branch is bound? | 16:58 |
| jam | Mez: bzr info | 16:58 |
| santagada | who does the macosx installer? | 16:59 |
| Mez | that doesnt metnion anything to do with bound branches | 16:59 |
| verterok | jelmer: no, the main issue to solve is how to include two builds of bzr-svn in the same dmg and check which one to use (for svn 1.4 and 1.5) | 16:59 |
| Mez | basically, I want to be able to automatically set a bind location, like I can with a push location | 17:00 |
| verterok | jelmer: as OSX 10.4 don't have any subversion, so any version could be installed :/ | 17:00 |
| santagada | the one for 10.5 was not updated, maybe I could generate it if it not contrived | 17:00 |
| Mez | but it doesnt seem that it wants to work | 17:00 |
| verterok | santagada: I build the OS X 10.4 dmg | 17:00 |
| verterok | santagada: phanatic builds the 10.5 one | 17:00 |
| santagada | but I use svn 1.5... so this could be a problem | 17:01 |
| jam | Mez: you should see something like: "checkout of branch: bzr+ssh://..." if it is a bound branch | 17:01 |
| santagada | verterok: there isn't a way to support both svn versions automatically at runtime? | 17:01 |
| jam | vila: I have to say, setting up much of anything on a 1TB disk takes a while. | 17:02 |
| jam | Even at a nice 70MB/s, it still takes 4Hours for software raid to sync the partitions | 17:03 |
| vila | jam: ? You mean formatting it ? Or any install ? | 17:03 |
| jam | well, raid syncing | 17:03 |
| jam | Even if I did the hardware-raid option | 17:03 |
| verterok | santagada: that is a question to jelmer, but I think the problem is compiling/linking of the bindings | 17:03 |
| jam | it wants to sync the drives | 17:03 |
| jam | which is a bitwise copy of everything | 17:03 |
| verterok | santagada: I think the 10.5 installer already provides bzr-svn | 17:03 |
| vila | ohhh, that I have no experience with :-) I'm going the SSD and full-backups-when-it-s-time route :) | 17:03 |
| jelmer | verterok, it's not possible to ship the required svn libs? | 17:03 |
| jam | vila: yeah, this is a server with some hard-to-get-back data | 17:04 |
| jam | so I like to have a bit of RAID | 17:04 |
| jam | I'd like to do full backups | 17:04 |
| jam | but w/ 300GB it gets difficult | 17:04 |
| verterok | santagada: as I don't have the sources, I'm starting to work on a 10.5 installer based on the 10.4 one | 17:04 |
| verterok | jelmer: don't really know, what libs should be shipped? | 17:04 |
| santagada | verterok: I have svn 1.5 from fink, and I have the bindings only for python-2.4 on fink also... | 17:05 |
| jelmer | verterok, the ones installed by svn, or rather, the ones that subvertpy links against | 17:05 |
| vila | jam: I can understand the hard-to-get-back data... not :-) I have 1,5TB available for compressed backups ran at night, some crossed fingers and most of the important bits under bzr and as such mirrored here and there :) | 17:05 |
| verterok | santagada: as far I know subvertpy can't be linked against the fink svn and used with other svn | 17:07 |
| verterok | santagada: other users might have the macports one or the Collabnet | 17:07 |
| verterok | version | 17:07 |
| verterok | jelmer: sadly I didn't looked subvertpy yet, the last time I worked on this subject, the binding was bundled with bzr-svn. I might take a look to it again :) | 17:09 |
| jelmer | verterok, ah, ok | 17:10 |
| santagada | verterok: so bundling the svn client is the only answer right? | 17:11 |
| verterok | jelmer: now that you mentioned this, if there is a way to compile the deps as static libs and link subretpy to that I think it should be fairly easy to bundle bzr-svn | 17:12 |
| verterok | santagada: yes, or build an installer for each possible svn installation :/ | 17:12 |
| verterok | jelmer, santagada: or compile subvertpy during the install (but that might be even more difficult) | 17:15 |
| jelmer | verterok, building against a static libsvn should be doable | 17:16 |
| santagada | verterok: needing to have xcode just to use bazaar is not optimal... | 17:16 |
| vila | verterok: not to mention requiring a C compiler :) | 17:16 |
| phinze | so CruiseControl.rb (the CI server we would probably use) only supports Subversion | 17:17 |
| phinze | it's possible for me to use bzr-svn to publish our trunk and project branches as svn urls for the CI server, no? | 17:17 |
| jelmer | phinze: you'll have to push them into svn manually, but yes | 17:17 |
| verterok | vila, santagada: sure, was just a crazy idea, thinking that most people using a vcs are developer :p | 17:17 |
| verterok | :) | 17:17 |
| vila | python, perl, java, etc are some languages that doesn't require a *C* compiler :-P | 17:18 |
| verterok | jelmer: ok, I'll try to build it that way | 17:18 |
| verterok | vila: yeap, having a 1GB monster (xcode) to use bzr is overkill | 17:19 |
| jelmer | phinze, bzr svn-serve is not mature enough yet | 17:19 |
| phinze | jelmer: so not really a viable solution currently for automatic continuous integration | 17:22 |
| vila | jam: is your default working PC 64 bits or 32 bits ? | 17:22 |
| jelmer | phinze, well, you can push using a cron-job or something like that | 17:22 |
| jam | vila: 32 | 17:22 |
| vila | that explains the warning I encounter then I presume: /home/vila/src/bzr/experimental/brisbane-core/bzrlib/chk_map.py:78: DeprecationWarning: 'i' format requires -2147483648 <= number <= 2147483647 | 17:24 |
| jam | perhaps | 17:24 |
| jam | could you get a backtrace for it? | 17:24 |
| vila | Using L solve the problem but I still find it strange that zlib.crc32(bit) can return such values... Oh wait it returns an unsigned. That still doesn't explain you never saw that warning... | 17:25 |
| jam | Considering where I'm seeing it: | 17:25 |
| jam | struct.pack('>i', zlib.crc32(bit) | 17:25 |
| jam | right | 17:25 |
| vila | That's the right line | 17:25 |
| jam | if it was returning an unsigned int | 17:25 |
| jam | then I would have expected to use ">I" | 17:25 |
| jam | it is returning a *signed* int on 32-bit python | 17:26 |
| jam | since it is just an "int" | 17:26 |
| jam | PyInt | 17:26 |
| jam | which is a 32-bit signed int on 32-bit platforms | 17:26 |
| jam | AIUI | 17:26 |
| vila | crc32 should returns a 32bits int so to be compatible you should use a long | 17:26 |
| vila | the question is is it signed or not | 17:27 |
| jam | on 32-bit I'm sure it is signed | 17:27 |
| jam | >>> zlib.crc32('aocehu') | 17:28 |
| jam | -2083739398 | 17:28 |
| jam | vila: what do *you* get ? | 17:28 |
| vila | 2211227898 :-) | 17:29 |
| vila | boom | 17:29 |
| jam | (The issue on Python is that a 32-bit unsigned int has to be held in a PyLong) | 17:29 |
| jam | vila: that is very unfortunate... :( | 17:29 |
| vila | jam: don't worry, better understand that *now* :) | 17:29 |
| vila | eerk, more hits while grepping crc32 than I hoped :-/ | 17:30 |
| jam | vila: what do you get for this: >>> zlib.adler32('\xff'*20) | 17:30 |
| jam | -784198675 | 17:30 |
| vila | 3510768621 | 17:31 |
| jam | vila: and you aren't doing anything fancy with your python, right? | 17:31 |
| vila | apart from running it on a 64bits processor, I don't think so | 17:31 |
| jam | IIRC we explicitly switched from adler32 to crc32 at some point in the past | 17:31 |
| jam | I thought because crc32 was supposed to be more stable across platforms, etc | 17:32 |
| jam | (we use it in the dirstate file) | 17:32 |
| jam | vila: see http://bugs.python.org/issue4903 | 17:33 |
| vila | I just checked dirstate.py and tune_gzip.py and AKAICS whe use them after some U32 conversions | 17:33 |
| jam | .. Guido prefers to keep Python 2.x always having signed values for the scattered crc functions. | 17:33 |
| jam | vila: output_lines.append('crc32: %s\n' % (zlib.crc32(inventory_text),)) | 17:34 |
| jam | I don't see a U32 conversion there | 17:34 |
| jam | do you? | 17:34 |
| vila | argh, missed that oen | 17:35 |
| vila | So, accessing a dirstate file from a 32 bits *and* a 64 bits hosts should blow up half of the time ? | 17:36 |
| verterok | jelmer: I'm building svn-1.5 with --enable-all-static atm, I'll let you know how it's going in a while (my oldish G4 needs some time to compile it) | 17:37 |
| jelmer | verterok, cool! | 17:37 |
| vila | Poor jam, that was too much :) | 17:40 |
| jelmer | :-) | 17:41 |
| Tak | argh, how do I get the status of one file using bzrlib? | 17:41 |
| vila | jam, come back ! It looks like that crc isn't used after all :) | 17:52 |
| fullermd | ISO9001 requires we have a CRC. It doesn't require that it be used :p | 17:53 |
| vila | That how I understand IS9001 too :-) | 17:53 |
| vila | The pity is that most of QA guys *think* that way though :-/ | 17:53 |
| vila | "I broke the code !!", "No problem, as long as you *document* it !" :-( | 17:54 |
| fullermd | Works for Microsoft. | 17:57 |
| ronny | lifeless: would there be any reasonable way to take partial merges into account when merging again? | 18:52 |
| rocky | jelmer: hey, is there a bzr-svn release for bzr 1.12 yet or a branch? | 18:55 |
| jelmer | rocky, the 0.5 branch | 18:55 |
| rocky | kk | 18:55 |
| jelmer | rocky, 0.5.0 will also work, but is slower | 18:56 |
| rocky | jelmer: the 0.5 branch is merely lp:bzr-svn right? | 19:03 |
| jelmer | rocky: yeah, lp:bzr-svn is a mirror of the 0.5 branch (between 0 and 8 hours out of date, usually) | 19:04 |
| rocky | oh yeah, you host the 0.5 branch yourself right? | 19:04 |
| jelmer | rocky, yep | 19:04 |
| jelmer | http://people.samba.org/bzr/jelmer/bzr-svn/0.5 | 19:05 |
| ronny | jelmer: sup? | 19:09 |
| === _thumper_ is now known as thumper | ||
| === cprov-lunch is now known as cprov | ||
| luke-jr | How do I switch a checkout to another upstream branch? | 20:12 |
| mwhudson | bzr switch | 20:13 |
| lifeless | ronny: well its a specific case of cherrypicking (in the content dimension) | 20:17 |
| lifeless | ronny: so the same things apply as for cherrypicking - yes, we need to when merging take it into consideration | 20:18 |
| lifeless | but we don't yet | 20:18 |
| === spm_ is now known as spm | ||
| rysiek|pl | yellow again | 20:34 |
| rysiek|pl | any teflon-underwear-wearing, sharks-with-lasers-defying bzr-replay-helping volounteers of yesterday present and willing to help? :) | 20:35 |
| * Lo-lan-do unleashes the sharks | 20:37 | |
| Lo-lan-do | Go kids go! Get him! | 20:37 |
| rysiek|pl | erm | 20:38 |
| * rysiek|pl kindly points out it was he who unleashed sharks - with lasers! - last time he was here | 20:38 | |
| rysiek|pl | and it *would* sound better a'la Mr Burns: | 20:39 |
| rysiek|pl | "Swim, my pretties!" | 20:39 |
| mwhudson | vila: ping | 20:39 |
| mwhudson | duelling sharks with lasers!! | 20:39 |
| rysiek|pl | ops, with lasers? | 20:39 |
| Lo-lan-do | Mine have laser swords and ninja powers. Do you surrender now? | 20:43 |
| rysiek|pl | ninjas can't catch you when you're on fire! | 20:43 |
| * rysiek|pl takes spills around some gasoline | 20:43 | |
| * rysiek|pl fires a match | 20:43 | |
| * RAOF fires up the petrol-powered, ninja zombie steampunk cyborgs. | 20:46 | |
| rysiek|pl | with lasers? | 20:49 |
| rysiek|pl | RAOF: ok, so I branched -r REV_BEFORE_FSCKUP my_branch | 20:49 |
| RAOF | Ok. | 20:50 |
| rysiek|pl | RAOF: and now I bzr replay -r REV_AFTER_FSCKUP.. my_branch | 20:50 |
| * RAOF notes that he hasn't done what you're trying to do before, so will only be able to offer general advice. | 20:50 | |
| rysiek|pl | hopefully this will give me a nice, clean, cruft-free branch | 20:50 |
| rysiek|pl | *but* | 20:50 |
| rysiek|pl | it will be bound to the original, crufted branch | 20:50 |
| rysiek|pl | so... | 20:50 |
| RAOF | What do you mean by "bound"? | 20:50 |
| rysiek|pl | oh, wait | 20:51 |
| rysiek|pl | checkouts are bound | 20:51 |
| rysiek|pl | branches aren't | 20:51 |
| rysiek|pl | m'kay | 20:51 |
| RAOF | Yes. Branches are not :) | 20:51 |
| rysiek|pl | so, this will give me my nice, cruft free branch | 20:51 |
| rysiek|pl | now, it's a "secondary" branch, ie it's my dev branch | 20:51 |
| rysiek|pl | so, to make the miracle happen in the upstream "trunk" branch - bzr push? | 20:52 |
| RAOF | I believe so. It might take push --overwrite, because you're doing some history rewriting. | 20:52 |
| rysiek|pl | right | 20:52 |
| === serg|away is now known as serg | ||
| poolie | hello all | 20:59 |
| poolie | hello jam | 20:59 |
| rysiek|pl | RAOF: hmmm, ok, I have gotten a conflict, resolved it and need to continue | 21:01 |
| rysiek|pl | RAOF: bzr rebase-continue tells me there is no rebase pending | 21:01 |
| rysiek|pl | RAOF: bzr replay-continue -> no such command | 21:01 |
| rysiek|pl | I am stuck | 21:01 |
| RAOF | rysiek|pl: And you're now out of my sphere of experience :( | 21:01 |
| rysiek|pl | ah, well | 21:01 |
| rysiek|pl | google, then | 21:01 |
| mwhudson | sounds like a question for jelmer :) | 21:03 |
| lifeless | rysiek|pl: now you replay from the point it stopped | 21:10 |
| jelmer | ronny: hi | 21:10 |
| lifeless | rysiek|pl: a newer bzr-rebase plugin may help, I fixed some bugs recently | 21:10 |
| rysiek|pl | lifeless: great, but the revision of the no_cruft branch when started replaying was 2315 | 21:11 |
| rysiek|pl | lifeless: and the revision I started replaying from was 2320 | 21:11 |
| rysiek|pl | lifeless: now, as I watched the output I have noticed, that the "Comitted revision <REVNO>" messages tell me about the <REVNO> of the no_cruft branhc at the given moment | 21:12 |
| rysiek|pl | lifeless: so orig:2320 becomes no_cruft:2316, etc | 21:12 |
| jelmer | rysiek|pl: hi | 21:13 |
| jelmer | rysiek|pl: replay doesn't handle conflicts at the moment | 21:13 |
| rysiek|pl | lifeless: as I understand, I should take the REVNO that was given in the last "Committed revno..." message, add 4 and start again from <LAST_REVNO+4>? | 21:13 |
| lifeless | jelmer: it spuriously conflicts without my patch | 21:15 |
| lifeless | jelmer: I dunno if you merged it or not | 21:15 |
| jelmer | lifeless: which patch? | 21:15 |
| * rysiek|pl brb | 21:15 | |
| jelmer | the one that had the --rewrite-nick ? | 21:16 |
| lifeless | yes amongst other fixes | 21:16 |
| jelmer | I didn't merge that one, but I think all your other branches are in | 21:16 |
| lifeless | rysiek|pl: rebase may not actually be the right tool on consideration, because we have to flatten all your other branches, so that they don't drag the bad history back in | 21:17 |
| * jelmer wonders what happened to Asabil's filter-branch plugiun | 21:17 | |
| phinze | hmm anybody have a way of appending the a diff to the bottom of $EDITOR when writing the commit message as well as the list of files modified? | 21:36 |
| lifeless | poolie: ping | 21:36 |
| lifeless | phinze: 'commit --show-diff' | 21:36 |
| poolie | phinze: commit --show-diff | 21:36 |
| poolie | lifeless: hi! | 21:36 |
| phinze | haha | 21:36 |
| phinze | just found it | 21:36 |
| poolie | phinze: where did you look for it? | 21:36 |
| phinze | thx lifeless, poolie | 21:36 |
| phinze | i was just glazing over it in bzr help ci | 21:37 |
| phinze | my bad | 21:37 |
| rysiek|pl | lifeless: huh? I don't think I understand the problem | 21:37 |
| lifeless | poolie: I have my allergy specialise appointment today @ 11:30; I'm pondering popping by your place beforehand, in the gap between transport and appointment. Does that fit for you? | 21:37 |
| poolie | sure | 21:37 |
| lifeless | rysiek|pl: say you have revisions 1,2,3,4,5, where 2 is bad | 21:37 |
| rysiek|pl | aye | 21:38 |
| lifeless | rysiek|pl: if 4 is a merge of a branch, made from 3, (so that branch went 3,4,5 of its own and got merges as '4' to the trunk | 21:38 |
| rysiek|pl | aye | 21:38 |
| lifeless | rysiek|pl: then, if we recreate the merge, and *still reference* the branch, we can follow history back down to 2, which is what we're trying to redact | 21:38 |
| lifeless | rysiek|pl: so in theory we need to replay the items of that branch seperately as well, and then its fine, but more simply is to just cherrypick merge '4' | 21:39 |
| rysiek|pl | something tells me now will be the conclusion | 21:39 |
| rysiek|pl | ah, there we are ;) | 21:39 |
| lifeless | 'replay' doesn't quite handle this case IIRC, I'd need to check the code again | 21:39 |
| rysiek|pl | hmm | 21:40 |
| rysiek|pl | ok, so what I understand from what you're saying is: | 21:40 |
| rysiek|pl | when doing a replay, use the first rev ABOVE the last merge into the original branch? | 21:41 |
| lifeless | no, I'm saying that replay may not be quite the tool you need, but bear with me a sec | 21:41 |
| rysiek|pl | sure | 21:42 |
| lifeless | jelmer: at least cherrypick http://bazaar.launchpad.net/~lifeless/bzr-rebase/dev/revision/116 if you won't take the rest | 21:42 |
| lifeless | jelmer: it makes the code match the documentation | 21:43 |
| phinze | okay so trying to get --show-diff to be default behavior... i need to use aliases, no? but aliases don't allow spaces in alias name. so i'm just stuck defining something like alias bzrci="bzr ci --show-diff" ? | 21:44 |
| phinze | or is there a better way? | 21:44 |
| lifeless | rysiek|pl: ok, try replay - just keep upping the revision to start from in step with any manual fixes you need to make, you can use 'bzr log' to see whether you have the right revno | 21:44 |
| lifeless | phinze: bzr can do command aliases, you can alias commit to commit --show-diff | 21:45 |
| phinze | ahh aliases *within* bzr... i always thought the reference was to bash aliases | 21:45 |
| rysiek|pl | lifeless: so, bzr replay (...), when conflicted fix manually and bzr replay again from where the conflict occured? | 21:45 |
| phinze | once again, misreading the docs [/shame] | 21:45 |
| lifeless | rysiek|pl: yes | 21:45 |
| rysiek|pl | ok | 21:46 |
| lifeless | rysiek|pl: once you're done, test by: | 21:46 |
| lifeless | 'bzr diff -r branch:../source' - that should show no changes | 21:46 |
| lifeless | and | 21:46 |
| lifeless | 'bzr branch /tmp/testsize' - then du -sh .bzr/repository | 21:46 |
| lifeless | if it has worked, you won't have that 400MB any more | 21:47 |
| jelmer | lifeless: any chance you can provide a patch ? :-) | 21:50 |
| ronny | jelmer: im wondering, can you guys manage to track partial merges better? | 21:51 |
| lifeless | jelmer: I did :P | 21:51 |
| lifeless | jelmer: I proposed the branch for merging | 21:51 |
| jelmer | lifeless: yeah, but that's got different things bundled together, cherrypicking just some causes conflicts.. | 21:51 |
| lifeless | jelmer: what does it conflict in ? | 21:52 |
| ronny | i hate that merging a subdir of a repo will cause conflicts later :/ | 21:52 |
| jelmer | lifeless: can't recall, it's been a while since I've tried | 21:52 |
| jelmer | ronny: I'm not really familiar with merge algorithms, but from what I hear from those who do cherrypicking is tricky | 21:53 |
| lifeless | jelmer: that commit is independent of the other two, I can't see it conflicting on anything other than NEWS, and its trivial | 21:53 |
| ronny | hmk | 21:53 |
| lifeless | jelmer: much faster really for you to merge and adjust than me to merge you, fix, push, and have you cherrypick the result (which won't apply anyway, because its still my full feature branch) | 21:53 |
| === WHATEVER is now known as UdontKnow | ||
| === abentley1 is now known as abentley | ||
| rysiek|pl | hmmm | 22:32 |
| spiv | lifeless: I figured out why I feel slightly hesistant about putting get_missing_compression_parents on VersionedFiles. | 22:32 |
| rysiek|pl | turns out quite a lot of cruft (about 1/2) was there from the beginning | 22:32 |
| rysiek|pl | is there a way to make a "lightweight" branch or something like that? | 22:33 |
| rysiek|pl | i.e. branch with the history of the last, say, 20-500 revisions? | 22:33 |
| rysiek|pl | *20-50 | 22:33 |
| jelmer | lifeless: Well, you could push a separate branch that provided just the bugfix, no need for me to cherrypick in that case. | 22:36 |
| jelmer | lifeless, Anyway, I don't object to doing the cherrypick + conflict resolution, I'll merge next time I work on rebase. | 22:37 |
| jelmer | lifeless: Looks like test_blackbox.py conflicts, and some of the tests in test_rebase.py fail | 22:43 |
| verterok | jelmer: this static svn build is getting difficult :/. until now I only succesfully builded a ppc-only version :-( | 22:56 |
| mwhudson | beuno: hello? | 23:17 |
| rysiek|pl | lifeless, RAOF, jelmer: I've got a fourth conflict in the same file, an the size of the no_cruft branch is 3x what was the size of the crufted branch | 23:20 |
| rysiek|pl | this does not bode well, I think I'll live it be | 23:21 |
| jelmer | verterok, :-( What are the other builds failing on? | 23:21 |
| jelmer | vila, ping | 23:26 |
| rysiek|pl | anywhoo, thanks for your help | 23:33 |
| rysiek|pl | cu all | 23:33 |
| lifeless | jelmer: ok, I'll look at that then | 23:53 |
| lifeless | jelmer: and get you a specific branch for it | 23:53 |
| lifeless | rysiek|pl: :( sorry | 23:53 |
| lifeless | I wish we had a polished-better-answer | 23:53 |
| rysiek|pl | lifeless: nothing to be sorry about, really | 23:54 |
| lifeless | spiv: so, I'm so close I can taste it | 23:54 |
| rysiek|pl | thanks a lot for your help, anyway | 23:54 |
| rysiek|pl | learned a lot about bzr during this | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!