| === BasicOSX [n=BasicOSX@216.243.156.81.real-time.com] has joined #bzr | ||
| === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr | ||
| === jelmer_ is now known as jelmer | ||
| === poolie [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr | ||
| poolie | hello | 12:29 |
|---|---|---|
| === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr | ||
| === ipkiss [i=ipkiss@nat/ecp/x-de0f73d1ca537c0b] has joined #bzr | ||
| === keir [n=keir@206-248-134-7.dsl.teksavvy.com] has joined #bzr | ||
| === fo2 [n=fog@213-140-22-78.fastres.net] has joined #bzr | ||
| igc | morning | 12:59 |
| mgedmin | when I bzr push a branch to my webserver with bzr+ssh://, how can I tell it to create an up-to-date working tree as well? | 01:01 |
| === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr | ||
| poolie | mgedmin, hi, | 01:02 |
| poolie | i'm not 100% sure this will work, but have you tried running 'bzr checkout' on that location? | 01:03 |
| === mgedmin finds a description in 'bzr help working-trees' | ||
| mgedmin | yes, bzr checkout . works, but bzr's help tells me I will have to manually ssh into the server and run bzr update in that directory after every push | 01:03 |
| mgedmin | (or look for some plugins to automate that) | 01:03 |
| === jml [n=jml@dsl-210-15-197-192-static.TAS.netspace.net.au] has joined #bzr | ||
| === pete__c [n=pete@032-463-246.area7.spcsdns.net] has joined #bzr | ||
| === fo2 [n=fog@213-140-22-78.fastres.net] has left #bzr [] | ||
| igc | bbiab | 01:28 |
| lifeless | mgedmin: there is a plugin that will invoke update for you on the remote server | 01:44 |
| === cprov is now known as cprov-afk | ||
| poolie | spiv, do you see the new bug about ^c in the smartserver? | 01:52 |
| === spiv looks | ||
| igc | lifeless: Assuming packs contain plain knits, how often are we expecting to be joining a plain knit source to an annotated knit target? | 02:07 |
| === n2diy [n=darryl@wlk-barre-208-103-148-58.dynamic-dialup.coretel.net] has joined #bzr | ||
| lifeless | igc: when we export a pack branch for a knit user | 02:19 |
| lifeless | igc: its ok for it to be slow if thats your concern | 02:20 |
| igc | yes it was | 02:20 |
| igc | so command wise, we're talking pull or branch right? | 02:20 |
| lifeless | push | 02:20 |
| lifeless | and pull | 02:20 |
| lifeless | and in rare cases upgrade | 02:20 |
| igc | thanks | 02:21 |
| lifeless | its not ideal for it to be slow, but its tolerable | 02:21 |
| ubotu | New bug: #144627 in bzr "TooManyConcurrentRequests raised when bzr+ssh push is interrupted" [Undecided,New] https://launchpad.net/bugs/144627 | 02:21 |
| lifeless | do you see why your logic was flawed ? | 02:21 |
| igc | yes | 02:21 |
| lifeless | cool | 02:21 |
| === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr | ||
| === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr | ||
| === jml_ is now known as jml | ||
| lifeless | jelmer: oh btw, did you want to use the bzr pqm? pqm is totally happy to have multiple projects... | 02:57 |
| lifeless | poolie: the index change in your branch - shoot that to bzr.dev directly please | 02:59 |
| poolie | lifeless, the docstrings? i thought i did | 02:59 |
| lifeless | the __repr__ | 02:59 |
| lifeless | I'm just checking for performance regressions in your patch [unlikely but needs to be done] | 03:00 |
| ubotu | New bug: #144633 in bzr "KeyError for BzrCheckError.message" [Medium,In progress] https://launchpad.net/bugs/144633 | 03:00 |
| poolie | lifeless, cherrypicking addition of a repr is not going to be very high on my list | 03:08 |
| poolie | unless you particularly want it in main | 03:09 |
| lifeless | I'll do it then | 03:11 |
| lifeless | I want nothing in my branch | 03:11 |
| lifeless | thats where I'm heading, and thats clearly 'done' as a piece of code, so no reason not to get it into bzr.dev | 03:11 |
| lifeless | ok its on its way | 03:16 |
| lifeless | poolie: your patch is about 1/2 second slower consistently | 03:23 |
| lifeless | poolie: I haven't tracked it down yet | 03:23 |
| poolie | which one? | 03:23 |
| === herzel [i=herzel@gateway/tor/x-7a7ae9847258843d] has joined #bzr | ||
| lifeless | I just merged from pack-repository | 03:24 |
| === jamesh [n=james@canonical/launchpad/jamesh] has joined #bzr | ||
| poolie | i'm glad you checked then | 03:32 |
| === poolie reads bialix's second win32 patch | ||
| lifeless | poolie: did you find all tests passing ? | 03:37 |
| === metze_away is now known as metze | ||
| lifeless | poolie: one thing I'm having some trouble telling with your patch is if it causes more index instances to be created | 03:46 |
| lifeless | I think it doesn't | 03:47 |
| === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr | ||
| === NamNguyen [n=namnt@203.162.163.50] has joined #bzr | ||
| poolie | will just finish this review then look | 04:00 |
| poolie | spiv, rise and shine :) | 04:01 |
| spiv | poolie: I'm here :P | 04:01 |
| poolie | :) | 04:04 |
| === jml__ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr | ||
| === jml [n=jml@ppp108-61.static.internode.on.net] has joined #bzr | ||
| === metze [n=metze@ip-217-172-181-76.mx-netz.de] has joined #bzr | ||
| === Verterok [n=ggonzale@75-108-235-201.fibertel.com.ar] has joined #bzr | ||
| Verterok | moin | 04:47 |
| poolie | Verterok, hi | 04:49 |
| poolie | lifeless, so do you know if there's a problem with that patch, or do you want me to look at it? | 04:49 |
| lifeless | poolie: I've merged it | 04:50 |
| poolie | there's no performance problem? | 04:50 |
| lifeless | its within the noise factor | 04:50 |
| lifeless | it looked 1/2 sec higher, but its possibly just noise | 04:51 |
| lifeless | there *may* be an issue with new indices being made when we should use existing ones, but its not showing up on incremental commit, and I alread knew of latent issues there | 04:52 |
| === herzel [i=herzel@gateway/tor/x-ab92dd9f8374c7b4] has joined #bzr | ||
| === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] | ||
| abentley | I hate the way everyone just assumes everything's on Launchpad. | 05:01 |
| abentley | Today I found out that people have been filing bugs on my branch of trac+bzr for months now. | 05:02 |
| abentley | With no one bothering to tell me about it. | 05:02 |
| lifeless | igc: ping | 05:03 |
| igc | hi lifeless | 05:04 |
| lifeless | abentley: there is a flag to tell lp if it should consider itself to be the bug tracker | 05:04 |
| lifeless | abentley: or not. Is that set for bzr-trac ? | 05:04 |
| abentley | How was I supposed to know trac+bzr was even in Launchpad? | 05:04 |
| lifeless | igc: I replied to your review of moving weave code out; did you re-reply ? | 05:04 |
| lifeless | abentley: oh hmm, thats a tougher one to answer :) | 05:05 |
| poolie | abentley, that is a good question | 05:05 |
| === igc checks | ||
| poolie | however, it's supposed to make it hard for people to file bugs if it's not approved by the owner | 05:05 |
| poolie | if someone else claimed to be the owner though... | 05:05 |
| lifeless | igc: cause I'd like to merge it :) | 05:06 |
| igc | I'm yet to reply ... | 05:06 |
| igc | we can cover it now if you like (i.e. here) | 05:07 |
| lifeless | please | 05:07 |
| igc | assume the first issue isn't ... | 05:07 |
| igc | i.e. the duplication is ok | 05:08 |
| abentley | Looks like Yann Houdique registered it way back when. | 05:08 |
| igc | I'd like the get_revision_graph API back there with just a docstring ... | 05:09 |
| igc | relying just on interface tests feels ... | 05:09 |
| igc | a bit of a stretch :-) | 05:09 |
| === igc looks ar 2nd issue again | ||
| === mlh_ [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr | ||
| igc | lifeless: I'm ok with the 2nd explanations as well, altohugh it might to good to put a comment in to that effect in the ... | 05:11 |
| igc | _get_revisions() method for weaves say. | 05:11 |
| igc | that's it ... | 05:11 |
| lifeless | igc: there is a comment there. | 05:11 |
| lifeless | igc: that was my point on the second one :) | 05:11 |
| igc | do you want an email summarising that? | 05:11 |
| lifeless | igc: AIUI its 'put a stub NotImplemented get_revision_graph method on the base class' | 05:12 |
| igc | yep | 05:12 |
| lifeless | igc: I think I can get by without a mail :) | 05:12 |
| igc | lifeless: that comment I was asking for ... | 05:15 |
| igc | looking again, putting it in _get_revisions in repository.py would be good because ... | 05:16 |
| igc | right now, the docstring says "without sanity checks" and ... | 05:16 |
| igc | you then proceed to do some I think? | 05:16 |
| lifeless | igc: mmm | 05:17 |
| lifeless | its checked for being a revision id or not | 05:17 |
| lifeless | but the results are not checked for sanity | 05:17 |
| === mlh_ [n=mlh@c211-30-211-232.belrs1.nsw.optusnet.com.au] has joined #bzr | ||
| poolie | abentley, i suggest what you do now, if you haven't already, is claim the project and then tell it bugs are not tracked in lp | 05:24 |
| poolie | unless in fact you do want to track them there | 05:24 |
| abentley | Yeah, I might track it there. | 05:24 |
| abentley | But in fact, I wasn't aware that anyone even cared about trac+bzr | 05:26 |
| lifeless | abentley: its one of the first questions people at conferences put to me | 05:28 |
| lifeless | 'its written in python, cool. Does it integrate with trac?' | 05:28 |
| abentley | Well, my answer would be "Kinda. For it to integrate properly, either Trac or Bazaar would have to change architectures" | 05:29 |
| lifeless | thats true | 05:30 |
| lifeless | I usually just say 'there is a plugin for trac, but I don't have personal experience with it' | 05:31 |
| poolie | i'm going to take a lunch break | 05:37 |
| poolie | biab | 05:37 |
| lifeless | good idea | 05:37 |
| cory | I installed trac+bzr at one point out of curiosity. What sort of differences are you saying are really irreconcilable? | 05:47 |
| abentley | They want to know what was the last-modifying revision of a directory, even for directories that aren't even branches. | 05:48 |
| abentley | That's the sort of thing. | 05:49 |
| abadger1999 | Oh cool. It's an abentley and he's talking trac+bzr stuff ;-) | 05:50 |
| cory | Yeah, that sort of thing doesn't really bother me, either because I expect it could be reasonably easily made optional in trac or omitted/lied about by trac+bzr when it's difficult/impossible to get. | 05:51 |
| abentley | Yeah, but people bitch about the lie. | 05:53 |
| cory | :) | 05:53 |
| jelmer | lifeless: Yes, it would be very nice if we could use the bzr pqm. | 05:53 |
| abentley | Seriously. Look in Launchpad, and you'll see people filing bugs about the null: and current: revisions, even though they're documented in the README. | 05:54 |
| lifeless | jelmer: Cool. Can you mail me a list of initial committers, and the build rule you want executed, plus where the writable location for the main trunk is (we could put that on bazaar-vcs.org if you like, I don't think poolie would object) | 05:55 |
| abadger1999 | heh, abentley I commented on that bug and added a patch to make them slightly better. | 05:55 |
| abentley | abadger1999: if you look at the scrollback, you'll see that I was not aware that any launchpad activity was taking place. | 05:56 |
| abadger1999 | Yep. I saw that. | 05:56 |
| poolie | lifeless, np here | 05:56 |
| abadger1999 | I was looking for you earlier to ping you about it. | 05:56 |
| === igc food | ||
| abentley | abadger1999: Sorry, I've been busy. | 05:57 |
| jelmer | lifeless: ok | 05:57 |
| abadger1999 | No problems, I fugred you were. | 05:57 |
| abentley | So what did you want me to look at? | 05:57 |
| abadger1999 | with the current: and null: changesets, I had two issues. | 05:58 |
| abadger1999 | the important one is that they're messing up the trac timeline RSS feed. | 05:58 |
| abadger1999 | Since it uses time.time() as its timestamp, everytime an RSS reader looks at it, it thinks there's a new entry when it's just current: re-occurring. | 05:59 |
| abadger1999 | I added a patch to the lp bug to have it use the same timestamp as the last revision. | 05:59 |
| abentley | That's bogus. This is why Atom has unique identifiers for postings. | 06:00 |
| abentley | Why not go the whole way and use the last revision instead of current:? And how much performance degradation did you see? | 06:01 |
| abadger1999 | I'm subscrbing to the feed via mugshot. | 06:02 |
| abadger1999 | So all the fedora developers were getting popups saying that there was new activity every time mugshot polled the RSS feed for the timeline. | 06:03 |
| abentley | Well, if RSS has unique IDS, that's bogus. If it doesn't, you should be using Atom. But my main concern about getting rid of current is the performance cost of determining the last-modified revision. | 06:05 |
| lifeless | we could build a cache | 06:05 |
| abadger1999 | Looking at the RSS feed, I don't see any ID :-( | 06:06 |
| lifeless | annotate each dir by whether paths under it changed | 06:06 |
| abadger1999 | Do you know how to get trac to serve atom? ?format=atom doesn't do it. | 06:07 |
| lifeless | build a dict {revid:{dirid:changed_revision}} | 06:07 |
| abentley | Sure, but then you've got to do invalidation and stuff. | 06:07 |
| abentley | Which seems just as espensive as not having a cache. | 06:08 |
| lifeless | abentley: no invalidation really, its static for a given revision | 06:08 |
| lifeless | abentley: I was not proposing this for bzr itself btw | 06:08 |
| cory | Hmm? I see a guid, but it looks like it has a timestamp on the end... | 06:08 |
| abentley | I'm talking about running trac against a repository with hundreds of branches. | 06:08 |
| lifeless | abentley: long term we should make answering the question cheaper; this is a proposal for the trac plugin to work with | 06:08 |
| abentley | I'm not talking about the issue of last-modified-revision for versioned directories. | 06:09 |
| lifeless | oh, perhaps I am confused | 06:09 |
| abentley | I'm talking about last-modified-revision for unversioned directories. | 06:09 |
| abadger1999 | cory: Right | 06:09 |
| lifeless | abentley: *blink*, is there such a thing? | 06:10 |
| abentley | For Trac's benefit, we pretend there is. | 06:10 |
| lifeless | so any dir whether it exists or not ? | 06:10 |
| abentley | Not "whether it exists or not"-- whether it exists as part of a versioned tree, or is used for layout in the repository. | 06:11 |
| lifeless | ah I get you | 06:13 |
| lifeless | so reporoot | 06:13 |
| lifeless | reporoot/project | 06:13 |
| lifeless | reporoot/project/branch1 | 06:13 |
| lifeless | noth reporoot and reporoot/project are given a 'last modified' | 06:13 |
| lifeless | s/noth/both/ | 06:13 |
| abentley | Given the path a/b/c, 'a' may be a plain directory. Its last-revision is 'current:' 'b' is a branch directory. Its last revision can be the branch last revision. 'c' is a versioned directory, and is not physically present in the repo, just referred to by 'b' | 06:13 |
| abentley | lifeless: Right. | 06:14 |
| lifeless | so the 'corect' last modification needs to move forward when any branch under an unversioned dir has its tip change | 06:14 |
| abentley | Yes, you could do it that way in theory. | 06:15 |
| lifeless | fraught with holes doing it on push etc | 06:15 |
| === jml_ [n=jml@ppp108-61.static.internode.on.net] has joined #bzr | ||
| lifeless | just trying to understand the 'definition' | 06:15 |
| lifeless | I see what you mean about the model mismatch | 06:16 |
| abentley | Yeah. | 06:16 |
| abentley | So now we have to define 'latest'. | 06:16 |
| abentley | We can't use the ancestry, because the branches may be unrelated. Do we use the revision timestamp? The time the tip was modified? | 06:17 |
| lifeless | what about stat of the dir ? | 06:18 |
| cory | This is vaguely relevant: http://trac.edgewall.org/wiki/VcRefactoring#SupportforMultipleRepositories | 06:21 |
| cory | At least just as confirmation that they might work on refactoring things for things structured like bzr. | 06:23 |
| abentley | lifeless: I don't think that helps. | 06:23 |
| abentley | Because if we're trying to find the latest revision, we must examine branches, not the directories containing them. | 06:23 |
| lifeless | if we accept that there is no well defined value | 06:25 |
| lifeless | then we can just show a fake commit, no message other than 'last modified on xxx' etc | 06:26 |
| abadger1999 | Right. I don't mind the lie, I just want the lie to remain the same between real commits. | 06:28 |
| abentley | Because trac does recursive comparisons, I don't know if that would work. | 06:28 |
| lifeless | using the dir stat would mean that adding a new branch or removing one would change the date | 06:29 |
| abentley | It could make the directory look like its contained directories weren't changing. | 06:29 |
| abentley | (except when branches were added or deleted) | 06:29 |
| lifeless | a commit id of date:secondssinceepoch | 06:29 |
| lifeless | might be a half-decent way to represent this | 06:29 |
| === BasicOSX [n=BasicOSX@warden.real-time.com] has joined #bzr | ||
| abentley | abadger1999: I think it could be harmful if the lie *didn't* change when commits happened. Which is I believe what lifeless is proposing. | 06:31 |
| abadger1999 | That would be more confusing than now, true. | 06:32 |
| abadger1999 | abentley: Is the current ancestry of current: to be trusted? ie: bzr_repo.previous_rev('current:') | 06:44 |
| abentley | I believe so. | 06:45 |
| abentley | Been months since I looked at the code though. | 06:45 |
| igc | lifeless: a question about converting deltas between annotated and plain knits ... | 06:46 |
| lifeless | sure | 06:46 |
| abadger1999 | abentley: k. My patch takes the timestamp of that rev and applies it to current: | 06:46 |
| igc | parse_linedelta returns something different to what ... | 06:46 |
| igc | lower_line_delta accepts ... | 06:47 |
| igc | it's works within ann-to-ann or plain-to-plain but ... | 06:47 |
| igc | not across the two | 06:47 |
| lifeless | ah yes | 06:47 |
| lifeless | thats my fault, I specialised it somewhat | 06:47 |
| igc | I'm concerned about ... | 06:47 |
| igc | changing that because it will impact ... | 06:47 |
| igc | perforamnce undoubtedly | 06:48 |
| igc | should I change it? | 06:48 |
| lifeless | so don't change it | 06:48 |
| abentley | abadger1999: So that means you potentially have multiple timestamps for current | 06:48 |
| lifeless | write a converter | 06:48 |
| abentley | Actually, no, I guess not. | 06:48 |
| igc | sure | 06:48 |
| abentley | You just don't have per-directory accuracy on that timestamp. | 06:49 |
| abadger1999 | Yeah. It's definitely a lie. | 06:49 |
| lifeless | bbiab | 06:52 |
| lifeless | igc: ring me if you need more info/discussion - going for lunch | 06:52 |
| igc | ok | 06:52 |
| === orospakr [n=orospakr@bas4-ottawa23-1167863943.dsl.bell.ca] has joined #bzr | ||
| abentley | abadger1999: So the problem is that bzr_repo.previous_rev('current:') can be quite expensive. | 06:53 |
| abentley | Theoretically less so for branch format 6. | 06:53 |
| abentley | (aka dirstate-tags) | 06:53 |
| abadger1999 | abentley: hmmm.... is bzr_repo.previous_rev() expensive in general or only when finding for 'current:'? | 06:57 |
| abentley | It's certainly more expensive for current:. It might not be cheap normally, either. | 06:58 |
| abentley | For current, it means scanning every branch in the repository. | 07:00 |
| abentley | I'm off to bed. | 07:00 |
| abadger1999 | 'night. | 07:01 |
| abadger1999 | Interesting. I think previous_rev() loads the history for the entire repo whenever it's called (unless history has previously been cached) | 07:02 |
| lifeless | abadger1999: knits have no partial index facility | 07:12 |
| lifeless | abadger1999: so accessing one revision loads the index of all revisions | 07:12 |
| abadger1999 | Ah. | 07:13 |
| === sevrin [n=sevrin@ns1.clipsalportal.com] has joined #bzr | ||
| === liw [n=liw@a91-154-119-10.elisa-laajakaista.fi] has joined #bzr | ||
| === arjenAU [n=arjen@ppp215-29.static.internode.on.net] has joined #bzr | ||
| lifeless | igc: I've reinstated the stat cache on packs | 07:59 |
| lifeless | igc: 4 second hit on initial commit (for now), but 10 second win on incremental commit | 07:59 |
| igc | awesome! | 07:59 |
| igc | I'll take the 10 sec win on incremental :-) | 07:59 |
| lifeless | pfft | 08:00 |
| lifeless | I figure that we don't need the stat cache when the fileid is new | 08:00 |
| lifeless | so I'm going to add a special case for no_parents, passed into path_content_summary | 08:00 |
| igc | sounds good | 08:00 |
| lifeless | should take it back to 1m20 | 08:01 |
| lifeless | and keep the 10 second win | 08:01 |
| === liw [n=liw@a91-154-119-10.elisa-laajakaista.fi] has left #bzr ["It's] | ||
| lifeless | so I now have 5 patches send in today | 08:01 |
| lifeless | *sent* | 08:01 |
| lifeless | (and not reviewed) | 08:01 |
| igc | I'm getting there - just sending mine to the ML now | 08:02 |
| igc | sent | 08:02 |
| vila | I intent to review the transport put related one | 08:02 |
| igc | I'll swap you - one review for >1 reviews :-) | 08:02 |
| vila | and hi all | 08:02 |
| igc | hi vila | 08:02 |
| === jml_ is now known as jml | ||
| vila | igc: np, if you take in your swap the project delivery I must do today ;P | 08:03 |
| lifeless | igc: 1:M | 08:03 |
| vila | about pycurl/urllib, what about making urllib the default for http and pycurl the default for https ? | 08:05 |
| vila | I'm a bit hesitant about it for coherence reasons, but on the other hand, we had many reports recently where pycurl failed were urllib worked... | 08:05 |
| vila | and I don't like dropping cretificate verification for https | 08:06 |
| lifeless | cretans eh? | 08:06 |
| vila | lol | 08:07 |
| vila | yeah, better than greeks :) | 08:07 |
| igc | lifeless: I'll do the path_content_summary review now unless you want a different one done 1st | 08:10 |
| lifeless | any order is fine | 08:10 |
| lifeless | igc: reviewed | 08:15 |
| igc | thanks | 08:16 |
| lifeless | igc: basically good; but you missed a large body of duplicate code in the tests | 08:16 |
| igc | ok | 08:16 |
| lifeless | if you move the assertions into your helper and rename it, you'll be good to go | 08:17 |
| igc | np | 08:17 |
| === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr | ||
| lifeless | igc: I've mailed you my current uncommitted-cause-its-experimental changes | 08:21 |
| lifeless | if you want to see how it performs on real hardware | 08:21 |
| igc | got those | 08:21 |
| lifeless | bbiab | 08:21 |
| === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr | ||
| === AfC [i=andrew@office.syd.operationaldynamics.com] has joined #bzr | ||
| === matkor [n=matkor@EUROCZESCI.wbs.ssh.gliwice.pl] has joined #bzr | ||
| === Lo-lan-do [n=roland@mirexpress.internal.placard.fr.eu.org] has joined #bzr | ||
| poolie | thanks for the review | 08:58 |
| lifeless | me? | 09:06 |
| vila | lifeless, poolie: looks like I'm 7 hours late to review the transport.put_file patch :-) | 09:09 |
| lifeless | vila: is it ok? | 09:09 |
| poolie | is there a problem with it? | 09:09 |
| lifeless | vila: or would you like it changed? | 09:09 |
| poolie | lifeless, yes, you | 09:09 |
| vila | lifeless: no, at first read it's ok, it will break webdav again, but it's mentionned in NEWS (for other transport implementors) and land sufficiently early to be taken into account | 09:10 |
| === Stevage [n=chatzill@mail.pfxcorp.com] has joined #bzr | ||
| Stevage | hello | 09:14 |
| Stevage | can anyone help me get TortoiseBZR to work? | 09:14 |
| Stevage | It compiles, but it doesn't seem to create any icons | 09:14 |
| Stevage | it does create shell extensions though - but they don't do much, and the 'diff' command seems broken | 09:15 |
| matkor | Stevage: pls fill bug report | 09:21 |
| matkor | but I have not seen much work recently in that area ... | 09:23 |
| Stevage | hmm | 09:24 |
| Stevage | pity | 09:24 |
| Stevage | I'd love to have tortoisebzr going | 09:24 |
| === pmezard [n=pmezard@dhcp26-226.enst.fr] has joined #bzr | ||
| matkor | so fill bugreport and keep presure on developers ;) | 09:26 |
| poolie | Stevage, alexander haro is the developer | 09:27 |
| igc | lifeless: ping | 09:27 |
| Stevage | yeah just reading the README | 09:27 |
| Stevage | I don't see that I installed it wrong, so I don't get it | 09:27 |
| poolie | suggest you cc him on your mail to get his attention | 09:28 |
| Stevage | also I think most of the shell extensions didn't appear | 09:28 |
| Stevage | what's his email? | 09:28 |
| poolie | amduser29 at gmail | 09:30 |
| Stevage | ta | 09:31 |
| Stevage | hmm | 09:44 |
| Stevage | it seems to be trying to find some method called CommitCommand | 09:44 |
| === alla [n=alla@soy.cyber.com.au] has joined #bzr | ||
| Stevage | which doesn't exist in bzr.dev/bzrlib | 09:45 |
| === n2diy [n=darryl@wlk-barre-208-103-148-58.dynamic-dialup.coretel.net] has joined #bzr | ||
| === lifeless [n=robertc@ppp245-86.static.internode.on.net] has joined #bzr | ||
| === james_w [i=jw2328@jameswestby.net] has joined #bzr | ||
| === jeremyb [n=jeremy@unaffiliated/jeremyb] has joined #bzr | ||
| === meuh [n=meuh@pdpc/supporter/active/meuh] has joined #bzr | ||
| === LarstiQ [n=larstiq@cust.7.157.adsl.cistron.nl] has joined #bzr | ||
| Stevage | has bzr been radically reorganised recently? | 09:45 |
| igc | no | 09:45 |
| igc | perhaps that's a method in a plugin? | 09:46 |
| Stevage | oh no, maybe I'm just confused | 09:46 |
| Stevage | yeah it is | 09:46 |
| Stevage | there's a CommitCommand.py | 09:46 |
| Stevage | I don't know why it can't find it | 09:46 |
| igc | :-) | 09:46 |
| Stevage | (I don't really speak python) | 09:46 |
| Stevage | command_mod = __import__('commands', globals(), locals(), [command_filename] ) | 09:46 |
| Stevage | command_mod = getattr(command_mod, command_filename) | 09:46 |
| Stevage | command_class = getattr(command_mod, command_filename) | 09:46 |
| Stevage | one of those is failing | 09:46 |
| Stevage | command_filename is "CommitCommand" | 09:47 |
| poolie | that seems a bit strange... | 09:47 |
| poolie | can you put the traceback in a pastebin? | 09:47 |
| Stevage | ok it's the first line | 09:48 |
| Stevage | there's no traceback | 09:48 |
| Stevage | it's just an exception | 09:48 |
| Stevage | um | 09:48 |
| Stevage | maybe that's nonsensical | 09:48 |
| lifeless | igc: yo | 09:50 |
| Stevage | I don't know how to get debugging output from it | 09:50 |
| igc | in the tests, where does the size "22" come from? | 09:50 |
| Stevage | those three lines of code above look pretty weird to me though | 09:51 |
| Stevage | especially #2 and #3 | 09:51 |
| lifeless | igc: which test | 09:56 |
| igc | test_file_content_summary_executable | 09:56 |
| lifeless | oh, thats the number of bytes in the file | 09:57 |
| lifeless | the content is generated by build tree - 'contents of path\n' IIRC | 09:57 |
| igc | ok - thanks | 09:57 |
| igc | not that easy to follow that in the code | 09:58 |
| igc | got it now | 10:00 |
| === mvo [n=egon@p54A67BA0.dip.t-dialin.net] has joined #bzr | ||
| === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr | ||
| ubotu | New bug: #144693 in bzr "remove {Branch,Tree}.print_file" [Low,Confirmed] https://launchpad.net/bugs/144693 | 10:06 |
| Lo-lan-do | Hmpf. | 10:08 |
| === Lo-lan-do gets bitten again | ||
| Lo-lan-do | Is there a way of having "bzr status" display paths relative to the current directory? | 10:08 |
| matkor | What is network usage in bzr over sftp comparing to rsync over ssh ? More or less ? | 10:08 |
| Lo-lan-do | It currently shows, f'rinstance, "foo/bar.txt" even when I'm in foo/ | 10:09 |
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| matkor | I mean doing rsync local remote vs bzr commit local, bzr push remote ? | 10:09 |
| Lo-lan-do | So "bzr add foo/bar.txt" (cut and paste) fails | 10:09 |
| igc | lifeless: that review sent to the list now fyi | 10:12 |
| === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr | ||
| igc | that knit join patch merged to bzr.dev now too | 10:14 |
| matkor | I have org-branch and branched from it modified-branch... now I want cherrypick some changes from modified-branch (I know which revisions) back to org-branch, what is easies way to do it ? | 10:20 |
| === pbor [n=urk@host126-78-dynamic.5-87-r.retail.telecomitalia.it] has joined #bzr | ||
| === allenap [i=allenap@nat/canonical/x-edc4d411a31e49a6] has joined #bzr | ||
| pbor | hi | 10:25 |
| pbor | not sure if it is on topic here, but if I branch from a launchpad import, will I be able to then push to the upstream svn repo with bzr-svn? | 10:25 |
| === pbor tried to to a local branch directly from the svn repo but it totally killed my machine... it required 1,5 gigs of mem | ||
| === igc food | ||
| pbor | mmm... I now realize that launchpad import is totatlly stale anyway, so nothing useful :/ | 10:32 |
| lifeless | igc: thanks | 10:38 |
| mwh | pbor: no, launchpad imports are different from bzr-svn imports | 10:43 |
| mwh | pbor: which import is it? i can try to find out why it's stale | 10:44 |
| pbor | mwh: gedit | 10:45 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| mwh | oh oops, that's still importing from anoncvs.gnome.org | 10:46 |
| pbor | mwh: just out of curiosity, how do launchpad imports and bzr-svn imports differ? | 10:50 |
| mwh | well, the glib answer is that they are created by different pieces of software :) | 10:51 |
| mwh | (launchpad imports are done by cscvs) | 10:51 |
| mwh | more technically, launchpad imports have random revids and bzr-svn imports have deterministic ones | 10:51 |
| pbor | okay | 10:51 |
| mwh | so if you run a cscvs import twice you'll get (as far as bazaar can tell) different histories | 10:52 |
| mwh | there are different trade offs | 10:52 |
| mwh | (roughtly speaking what bzr-svn does is harder and much more of a commitment in some ways) | 10:52 |
| === gabe [n=gabriel@91.84.56.254] has joined #bzr | ||
| === gabe [n=gabriel@91.84.56.254] has joined #bzr | ||
| pbor | mwh: btw, looks like this is my problem with yesterday's import https://bugs.launchpad.net/bzr-svn/+bug/54253 | 10:59 |
| ubotu | Launchpad bug 54253 in bzr-svn "Excessive memory usage in bzr-svn" [Undecided,Confirmed] | 10:59 |
| mwh | you can often get away with killing the process and having it resume from some point | 11:01 |
| mwh | current thinking on that bug is that it's a problem in the python-svn bindings i think | 11:01 |
| pbor | mwh: how do I resume? | 11:01 |
| mwh | what stage had it got to when you killed it? | 11:02 |
| pbor | no idea, I had to hard reboot :/ | 11:02 |
| mwh | ugh | 11:02 |
| lifeless | pbor: rather than doing bzr branch, do 'bzr init --dirstate-with-subtree', then do 'bzr pull svn://'... | 11:02 |
| pbor | lifeless: what does that give me? | 11:03 |
| lifeless | if you hit ctrl-c | 11:04 |
| lifeless | just do 'bzr pull svn://' again | 11:04 |
| lifeless | and it will resume | 11:05 |
| pbor | ah | 11:05 |
| === bigdo2 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| === Mez [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| lifeless | mwh: you might like to start dogfooding packs for codeview; we're closing in on a first release of it in the next week or two | 11:24 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| lifeless | mwh: if it sucks for you, *now* is the time to hear. | 11:24 |
| jrydberg_ | lifeless: what's the status of packs? | 11:24 |
| lifeless | mwh: there's two known issues may affect you; annotations will be no longer cheap in the first release (plain-knits always, and no cache implemented yet). Secondly partial index reading has not landed yet. | 11:25 |
| lifeless | jrydberg_: good. | 11:25 |
| lifeless | jrydberg_: initial commit is nice and fast :) | 11:25 |
| jrydberg_ | lifeless: what about push and pull? | 11:25 |
| lifeless | initial push runs about 20% slower than rsync | 11:26 |
| lifeless | ditto pull | 11:26 |
| lifeless | needless to say this is hugely faster than knits. | 11:26 |
| jrydberg_ | how about incrimental updates? | 11:26 |
| lifeless | they are ok, but not great because the text indices are read entirely still, and they are much larger than the individual indices that knit repos have | 11:27 |
| lifeless | so we're reading more index data | 11:27 |
| lifeless | though there is plenty of room to optimise that even before partial index reads come in | 11:27 |
| lifeless | we don't do ghost filling automatically in packs | 11:28 |
| lifeless | so we can examine just incremental data, and thats in the most recent (and smallest) packs, so checking them first for content will usually be a win | 11:28 |
| mwh | lifeless: makes sense | 11:28 |
| jrydberg_ | lifeless: i see | 11:28 |
| mwh | lifeless: can i get a bzr.dev | 11:28 |
| mwh | lifeless: can i get bzr.dev in packs somewhere? | 11:29 |
| lifeless | fwiw, by nice and fast on initial commit, its 1m30 wall clock for me in my latest not-quite-committed stuff; thats the same as hg on this machine (well actually a little faster) | 11:29 |
| lifeless | mwh: yes; see my dogfooding emails to the list | 11:29 |
| mwh | lifeless: subject? | 11:31 |
| === Mez [n=mez@ubuntu/member/mez] has joined #bzr | ||
| jrydberg_ | lifeless: why do we have so large indexes then? can't we have a pack-index, and then have per-pack indeces (either as a separate file, or in the pack header) ? | 11:32 |
| === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr | ||
| lifeless | jrydberg_: thats what we have | 11:34 |
| lifeless | jrydberg_: its just that rather than N knit indices | 11:34 |
| lifeless | where N is the number of file ids | 11:34 |
| jrydberg_ | lifeless: well, the pack index doens't have to be that big, does it? | 11:34 |
| jrydberg_ | pack: <contained revisions> | 11:34 |
| lifeless | we have one text index per pack, which has the data for all N fileids-versions in that pack | 11:34 |
| lifeless | jrydberg_: we limit the number of packs to prevent latency explosion due to one pack per commit, which would be going back to the arch days | 11:35 |
| jrydberg_ | so you're doing auto repacking, is what you're saying? | 11:36 |
| lifeless | yes | 11:36 |
| lifeless | so the text index size is not excessive, its smaller than the combined .kndx files | 11:37 |
| lifeless | its just that we're reading more than we need to | 11:37 |
| jrydberg_ | when i was experimenting with a blob-like format, i did the repacking on incrimental updates (push or pull) | 11:37 |
| lifeless | how far did you get; what conclusions did you draw? | 11:38 |
| jrydberg_ | the only conclusion i came to was that it was often smarter to fetch a bit more data, if the data is grouped in a fetch-frendly way, than to do all kind of smart stuff on the client side to minimize the amout of data to fetch | 11:40 |
| jrydberg_ | but that isn't really rocket science | 11:40 |
| lifeless | yeah | 11:40 |
| lifeless | latency hurts | 11:40 |
| lifeless | small reads often increase latency | 11:41 |
| jrydberg_ | i also experimented with using already defined container formats | 11:41 |
| jrydberg_ | such as each blob being a .zip | 11:41 |
| jrydberg_ | but the zip-format is kinda borked | 11:41 |
| === arjenAU [n=arjen@ppp215-29.static.internode.on.net] has joined #bzr | ||
| === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr | ||
| lifeless | jrydberg_: 7z might have been reasonable | 11:42 |
| lifeless | jrydberg_: but being able to controll index locality of reference seemed quite important to me | 11:43 |
| lifeless | to make client reads more effective without insanely complex logic on the read size | 11:43 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr | ||
| === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr | ||
| jrydberg_ | mmm | 11:45 |
| === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr | ||
| lifeless | jrydberg_: the current index doesn't do this, but the one in development by keir does | 11:47 |
| lifeless | it groups nodes by the graph, giving graph walking with less roundtrips (and roundtrips are our biggest problem) | 11:47 |
| lifeless | jrydberg_: packs are still knit delta based | 11:48 |
| lifeless | jrydberg_: please, dogfood :) | 11:48 |
| jrydberg_ | hehe | 11:48 |
| jrydberg_ | how many files are fetched before the actual pack-data is started to be brought in? | 11:49 |
| lifeless | jrydberg_: well, theres .bzr/format, .bzr/repository/format | 11:50 |
| lifeless | jrydberg_: then .bzr/repository/pack-names (the index of packs) | 11:50 |
| === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr | ||
| === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr | ||
| lifeless | jrydberg_: I'm out for the night I think | 11:52 |
| jrydberg_ | you need to figure out the head of the branch too? | 11:52 |
| === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr | ||
| lifeless | jrydberg_: well depends on the operation you're doing; if you need a branch info its .bzr/branch/format and .bzr/branch/somethingorother | 11:52 |
| lifeless | ciao | 11:52 |
| mwh | hm | 11:53 |
| mwh | ../bzr/pack-repository.knits/bzr get http://people.ubuntu.com/~robertc/baz2.0/repository | 11:53 |
| mwh | seems to be doing an awful lot of nothing | 11:53 |
| lifeless | mwh: I've just updated the pack-repository.knits branch FWIW | 11:53 |
| lifeless | mwh: there is no progress bar at the moment | 11:53 |
| mwh | lifeless: oh | 11:54 |
| mwh | that was probably it then | 11:54 |
| lifeless | ciao, for real | 11:55 |
| === lapthrick [n=mathrick@users.kollegienet.dk] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === Mez_ [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| mwh | does keir irc? | 12:19 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === Mez [n=mez@ubuntu/member/mez] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === sabdfl [i=sabdfl@nat/canonical/x-ca265d16ed22ff60] has joined #bzr | ||
| === bac_afk is now known as bac | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| sabdfl | hey revisionistas | 01:04 |
| Peng | Good morning! | 01:05 |
| === Peng goes to bed. | ||
| sabdfl | night pe | 01:05 |
| sabdfl | ng | 01:05 |
| Peng | :D | 01:05 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === schierbeck [n=daniel@dasch.egmont-kol.dk] has joined #bzr | ||
| === Zindar [n=erik@stockholm.ardendo.se] has joined #bzr | ||
| === ignas [n=ignas@office.pov.lt] has joined #bzr | ||
| ignas | hi | 01:27 |
| ignas | is there a way to make bzr display relative paths for bzr st? | 01:27 |
| dato | not at the moment | 01:27 |
| matkor | How bzr handles soft links ? /branch-root/link-to-dir-out-of-branch ? Will link-to-dir-out-of-branch be threated as subdir and versioned ? | 01:32 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| mwh | the symlink will be versioned | 01:40 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === mrevell is now known as mrevell-lunch | ||
| matkor | mwh: No way to force bzr to version contents of symlink not symlink itself ? | 01:46 |
| mwh | not that i know of | 01:46 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| mwh | AfC: hi, are you involved in the gnome-java bindings? | 02:02 |
| lifeless | matkor: we do version the contents - the thing pointed at | 02:07 |
| lifeless | matkor: I think you'd need to give us some use cases, help us design what you'r interested in bzr doing, for us to help you get bzr to do it | 02:07 |
| lifeless | mwh: ping | 02:08 |
| mwh | lifeless: hi there | 02:08 |
| lifeless | did you get a pack error ? | 02:08 |
| mwh | lifeless: yes i dud | 02:08 |
| mwh | did | 02:08 |
| lifeless | with the latest branch ? | 02:08 |
| mwh | yes | 02:09 |
| lifeless | ok | 02:09 |
| lifeless | try this | 02:09 |
| lifeless | bzr init --experimental | 02:09 |
| lifeless | bzr pull /path/to/your/knit/based/bzr.dev | 02:09 |
| === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr | ||
| lifeless | bzr push ../newpath | 02:09 |
| lifeless | (this should make a fresh packs repo locally and clone it to a second fresh packs repo | 02:09 |
| mwh | 'bzr' here being my pack-repository.knits tip ? | 02:10 |
| lifeless | yes | 02:10 |
| mwh | ok | 02:10 |
| lifeless | revno 2783 | 02:10 |
| mwh | that's what i have | 02:10 |
| lifeless | yay | 02:12 |
| mwh | ok, it's running | 02:12 |
| lifeless | igc's patch has landed, time for the next pack format change tomorrow | 02:12 |
| lifeless | if this works I probably have something weird in my repo | 02:13 |
| lifeless | would not surprise me :) | 02:13 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| lifeless | how did it go ? | 02:15 |
| abentley | Hey, when the going gets weird, the weird turn pro. | 02:15 |
| === marianom [n=marianom@ubuntu/member/marianom] has joined #bzr | ||
| lifeless | abentley: :) | 02:15 |
| lifeless | abentley: Are you comfortable with packs being cached-annotation-less in their first iteration ? | 02:15 |
| lifeless | I am, though more from necessity than desire. | 02:16 |
| mwh | lifeless: first pull completed | 02:16 |
| lifeless | mwh: ok, you now should have a .bzr/packs/* | 02:16 |
| lifeless | mwh: with one pack in it | 02:16 |
| mwh | (i'm on my powerbook this week, slooooow) | 02:16 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| mwh | lifeless: .bzr/repository/packs ? | 02:17 |
| lifeless | yes | 02:17 |
| mwh | ok, then yes | 02:17 |
| lifeless | I am asleep | 02:17 |
| lifeless | this is a ghost typing | 02:17 |
| mwh | noted | 02:17 |
| lifeless | mwh: so, try a push | 02:17 |
| mwh | trying | 02:17 |
| lifeless | it should be a) successful, and b) pleasantly faster | 02:18 |
| abentley | lifeless: As something we release? Seems like they couldn't be default if they had a performance regression like that. But an optional format for those who understood the tradeoffs would be okay. | 02:18 |
| lifeless | abentley: I am comfortable with that. | 02:18 |
| lifeless | abentley: I think it gives us something to talk to the mozillas of the world with | 02:18 |
| abentley | Sure. | 02:19 |
| lifeless | abentley: btw, I have incremental commits in the moz tree down to 24 seconds | 02:19 |
| === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| lifeless | and a fairly good idea of where I'm going to drop the next 10 seconds off | 02:19 |
| lifeless | abentley: which *should* drop off on initial commit too | 02:20 |
| lifeless | mwh: has it finished? | 02:21 |
| mwh | lifeless: no | 02:21 |
| lifeless | mwh: is it showing aprogress bar ? | 02:21 |
| mwh | no | 02:21 |
| lifeless | is your cpu locked at max? | 02:21 |
| mwh | yes, pretty much | 02:21 |
| lifeless | if your disk is ticking over, not idle but not busy, you are cpu bottlenecked | 02:22 |
| mwh | certainly seems that way | 02:23 |
| lifeless | you can see how much data has been copied by looking in .bzr/repository/uploads | 02:23 |
| mwh | seems like it's about 1/3 done | 02:23 |
| mwh | lifeless: the push failed in the same way | 02:25 |
| lifeless | so, you are probably locked in gunzipping the knit segments. | 02:25 |
| mwh | next = self.get_parents(cursor)[0] | 02:25 |
| mwh | IndexError: tuple index out of range | 02:25 |
| lifeless | mwh: ah, its the old issue I mentioned in my how to dogfood notes. | 02:26 |
| lifeless | bzr has an unreferenced text | 02:26 |
| lifeless | look in .bzr/repository/packs | 02:26 |
| lifeless | in the new repo, is it empty? | 02:26 |
| mwh | no, it has a 54 meg file | 02:27 |
| lifeless | good | 02:27 |
| lifeless | I know what the problem is; its bad data in bzr.dev that knit based repos tolerate | 02:28 |
| mwh | ok | 02:28 |
| lifeless | (bad data == an index that is not quite right) | 02:28 |
| lifeless | your bzr.dev in pack format will work fine | 02:28 |
| lifeless | it just can't be cloned by bzr because bzr will not copy quite enough data | 02:28 |
| mwh | ok, i'll play with pointing loggerhead at that in a bit | 02:29 |
| lifeless | there is a patch to run on the knit format repo to fix this; its been written by Aaron, and tweaked by spiv | 02:29 |
| mwh | ok, i saw those mails go by | 02:29 |
| lifeless | not *quite* up for using it yet, when we do what I asked you to do will work | 02:29 |
| lifeless | right, please let me know how loggerhead plays with packs. | 02:29 |
| mwh | first: lunch | 02:30 |
| mwh | :) | 02:30 |
| lifeless | night | 02:33 |
| lifeless | *yawn* | 02:33 |
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === mw [n=mw@189.146.13.202] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| lapthrick | mwh: loggerhead's loggerhead seems very much dead | 02:42 |
| lapthrick | at http://www.lag.net/branches/loggerhead/loggerhead_dev/ | 02:42 |
| AfC | mwh: pong, yes | 02:45 |
| mwh | AfC: and you use bzr already for all the java-gnome development? | 02:45 |
| AfC | "already"? | 02:45 |
| mwh | ehm ;) | 02:46 |
| AfC | We've been using Bazaar since ... | 02:46 |
| === AfC does bzr log -r 0..1 | ||
| mwh | lapthrick: that's nothing to do with launchpad | 02:46 |
| mwh | lapthrick: launchpad's is at urls like http://codebrowse.launchpad.net/~mwhudson/loggerhead/production/changes | 02:46 |
| lapthrick | mwh: I never said it had anything to do with launchpad, I was just pointing out in the hope you'd be more able to fix it | 02:47 |
| === mrevell-lunch is now known as mrevell | ||
| mwh | lapthrick: oh, sorry, misread | 02:47 |
| AfC | mwh: well, since the beginning. First commits (which imported a huge whack of stuff) were Oct '06 | 02:47 |
| mwh | lapthrick: not my site | 02:47 |
| mwh | AfC: cool | 02:47 |
| AfC | 829 revisions, 14 committers. I suppose that's starting to edge out of small | 02:49 |
| lapthrick | AfC: I still don't understand how you can put up with that ugly lump of a language :) | 02:49 |
| AfC | Python? That's why we ditched it :) | 02:50 |
| === herzel [i=herzel@gateway/tor/x-c1bf8afd4dde4d29] has joined #bzr | ||
| === allenap [i=allenap@nat/canonical/x-7309a8c9293a563b] has joined #bzr | ||
| === grimeboy [n=grimboy@85-211-244-198.dsl.pipex.com] has joined #bzr | ||
| pbor | lifeless: I am now trying your suggestion of using bzr init --dirstate-with-subtree', then do 'bzr pull svn://', but it doesn't seem to help much: | 03:17 |
| pbor | lifeless: resume works but ends up using the same amount of memory | 03:17 |
| pbor | (incidentally, resume is really slow, unless it's the progress indicator that it is not clear) | 03:19 |
| corporate_cookie | abadger1999: I'm having a bit o' trouble building a rpm for bzr-0.17; could you perhaps lend a bit of a hand ? | 03:19 |
| jelmer | pbor: how much revisions are you trying to pull? | 03:20 |
| pbor | jelmer: 5923 | 03:22 |
| pbor | jelmer: I am not interested in the whole history... can I tell it to start from a revision? (I recall git-svn doing something similar, but I am not sure if it makes sense for bzr) | 03:23 |
| jelmer | pbor: no, that's not possible in bzr yet (requires a feature called historyhorizon) | 03:23 |
| jelmer | pbor, you can fetch sets of 500 revisions for example, by running 'bzr pull -r500', 'bzr pull -r1000', etc | 03:24 |
| pbor | jelmer: will that help keeping the memory usage under control? | 03:24 |
| === ignas [n=ignas@office.pov.lt] has left #bzr ["Download] | ||
| jelmer | pbor: yes, it will free the memory after each set of revisions | 03:26 |
| pbor | jelmer: ok, thanks for the suggestion.. /me tries | 03:26 |
| pbor | jelmer: any chance to implement the same workaround of hg? Or will the python-svn bug be resolved soon? | 03:27 |
| jelmer | pbor:it's not just the memory usage of svn.ra.get_log() that's a problem | 03:27 |
| jelmer | pbor: subversion seems to've fixed a bunch of memory problems in 1.5 | 03:29 |
| pbor | jelmer: ok... though if that workaround at least makes hg usable I hoped the same could work for bzr | 03:29 |
| pbor | jelmer: btw, it seems the -r trick is working very well | 03:30 |
| pbor | jelmer: I am already up to -r 3000 | 03:30 |
| pbor | jelmer: maybe for now the conversion could be batched in blocks of 1000 revisions | 03:31 |
| pbor | or something like that | 03:31 |
| Lo-lan-do | I think I saw something ot that effect in a NEWS file recently :-) | 03:31 |
| === vila [n=vila@lec67-4-82-230-53-244.fbx.proxad.net] has joined #bzr | ||
| jelmer | pbor: that's a very large amount of work I'm afraid | 03:32 |
| Lo-lan-do | Isn't that what revno. 711 was about? | 03:33 |
| pbor | jelmer: okay, so maybe this trick should be at least documented... one could whip up a quick shell script to parse svn info and then run bzr pull -r$i+500 until it recahes head :) | 03:34 |
| === sii [n=sii@tranquillity.sii.se] has joined #bzr | ||
| === BasicOSX [n=BasicOSX@216.243.156.81] has joined #bzr | ||
| === fog [n=fog@debian/developer/fog] has left #bzr [] | ||
| === p4tux [n=p4tux@189.169.63.63] has joined #bzr | ||
| === bigdog [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| === orospakr [n=orospakr@132.213.238.4] has joined #bzr | ||
| === Mez_ [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| === niemeyer [n=niemeyer@200.140.230.150] has joined #bzr | ||
| abadger1999 | corporate_cookie: What's the error? | 04:36 |
| corporate_cookie | abadger1999: i've got it : ) | 04:36 |
| corporate_cookie | but thanks for the responce | 04:36 |
| abadger1999 | Cool :-) | 04:37 |
| corporate_cookie | im still a little green ...but i'm figuring stuff out | 04:37 |
| === corporate_cookie [n=richie@seraphim.asbury.edu] has joined #bzr | ||
| === BasicOSX [n=BasicOSX@errant.real-time.com] has joined #bzr | ||
| === hexmode [n=user@24.115.83.248.res-cmts.eph.ptd.net] has joined #bzr | ||
| === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr | ||
| === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| === bigdo1 [n=scmikes@72-197-8-8-arpa.cust.cinci.current.net] has joined #bzr | ||
| === RichardL is now known as rml | ||
| === niemeyer [n=niemeyer@200.140.230.150] has joined #bzr | ||
| === Mez_ [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| === cprov is now known as cprov-lunch | ||
| pbor | jelmer: I let the pull from svn run with a script that pulled 100 revisions at a time but now it errors out in a somewhat surprising way: | 05:39 |
| pbor | bzr: ERROR: Requested revision: u'4900' does not exist in branch: SvnBranch('svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk') | 05:39 |
| pbor | but... | 05:39 |
| jelmer | pbor: bzr revno's are per-branch | 05:39 |
| pbor | URL: svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk | 05:39 |
| pbor | Repository Root: svn+ssh://pborelli@svn.gnome.org/svn/gedit | 05:39 |
| pbor | Repository UUID: 553ab114-d825-0410-8aca-8eebfce848a2 | 05:39 |
| pbor | Revision: 5923 | 05:39 |
| jelmer | the svn revno is per-repository | 05:40 |
| pbor | jelmer: mmm, so is it normal? | 05:40 |
| pbor | ah, so it discarded all revisions that didn't affect trunk? | 05:40 |
| jelmer | well, didn't fetch them at all | 05:40 |
| pbor | neat! | 05:41 |
| pbor | so one more pull and I am done! | 05:41 |
| pbor | :) | 05:41 |
| jelmer | this sort of stuff (memory issue as well) is documented in bzr-svn trunk, and will be in 0.4.4 | 05:41 |
| pbor | jelmer: great, thanks a lot for your help (and for bzr-svn!) | 05:42 |
| pbor | now I just need to figure out a patch to test my new toy | 05:42 |
| pbor | but first of all I'll push the import to a remote ssh, so that if I screw up I can just branch that | 05:44 |
| === BasicOSX [n=BasicOSX@errant.real-time.com] has joined #bzr | ||
| === michelp [n=michelp@69-30-72-119.dq1sf.easystreet.com] has joined #bzr | ||
| === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr | ||
| === kiko is now known as kiko-fud | ||
| === jrydberg [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr | ||
| === rml [n=Skippy@78.32.35.169] has joined #bzr | ||
| === dpm [n=dpm@p54A135ED.dip0.t-ipconnect.de] has joined #bzr | ||
| === asak [n=alexis@201-27-61-62.dsl.telesp.net.br] has joined #bzr | ||
| === cprov [n=cprov@canonical/launchpad/cprov] has joined #bzr | ||
| === bac is now known as bac_afk | ||
| === quicksilver [n=jules@212.69.38.59] has joined #bzr | ||
| === EdwinGrubbs [n=edwin@cpe-66-25-92-150.satx.res.rr.com] has joined #bzr | ||
| === asabil [n=asabil@62.70.2.252] has joined #bzr | ||
| === rml [n=Skippy@78.32.35.169] has joined #bzr | ||
| === marianom [n=marianom@ubuntu/member/marianom] has left #bzr [] | ||
| === zyga [n=zyga@ubuntu/member/zyga] has joined #bzr | ||
| === jrydberg__ [n=Johan@c80-216-246-123.bredband.comhem.se] has joined #bzr | ||
| === GaryvdM [n=chatzill@mtngprs2.mtn.co.za] has joined #bzr | ||
| pbor | if I do bzr log | less and then ctrl+C before it's finished bzr gives a traceback... | 08:10 |
| pbor | which is a bit annoying since it triggers ubuntu bug reporting tool | 08:10 |
| radix | yeah, that seems to be new behavior | 08:11 |
| radix | or reintroduced behavior | 08:11 |
| radix | ('q' instead of ctrl+C reproduces it just as well) | 08:11 |
| james_w | I think reintroduced as well. | 08:12 |
| james_w | is it a pipe error? (I can't remember the name) | 08:13 |
| === cprov is now known as cprov-afk | ||
| pbor | yep, IOError: [Errno 32] Broken pipe | 08:13 |
| === fkumro [n=fkumro@pool-71-186-136-74.bflony.east.verizon.net] has joined #bzr | ||
| fkumro | I'm just reading through the docs but I cannot find out what the command would be to revert a file to before a commit | 08:26 |
| GaryvdM | bzr revert | 08:26 |
| fkumro | heh I feel foolish | 08:27 |
| GaryvdM | :-) | 08:27 |
| fkumro | how would I use it ? Specify the file and revno ? bzr revert file? | 08:28 |
| === herzel [i=herzel@gateway/tor/x-795fa8905baac061] has joined #bzr | ||
| radix | fkumro: bzr revert -r revno file | 08:29 |
| fkumro | thanks again | 08:29 |
| radix | fkumro: if you don't pass "-r", it just reverts to the latest version (i.e. throwing out all changes only made in the working tree) | 08:29 |
| ipkiss | see bzr revert -h for more details | 08:29 |
| fkumro | good to know that about the -r flag | 08:30 |
| === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr | ||
| === cprov-afk is now known as cprov | ||
| === Mez_ [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| === asabil [n=asabil@ti0035a340-0469.bb.online.no] has joined #bzr | ||
| === bac_afk is now known as bac | ||
| === joseo [n=user@84.123.19.235.dyn.user.ono.com] has joined #bzr | ||
| joseo | hi | 09:09 |
| joseo | anybody knows if its possible to rename .bzr to something else like _bzr | 09:10 |
| joseo | I'm having problems with ftp uploaded and I think are related to this | 09:11 |
| joseo | so quiet here :) | 09:14 |
| GaryvdM | Hi - sorry - don't know | 09:15 |
| fkumro | I would help but I just started using bzr for my projects today heh | 09:15 |
| GaryvdM | What are your problems? | 09:15 |
| GaryvdM | Steps to reproduce? | 09:16 |
| james_w | joseo: no way apart from patching the source. | 09:17 |
| joseo | Me too I'm starting today | 09:17 |
| joseo | or trying | 09:17 |
| joseo | :) | 09:17 |
| joseo | james_w:okay, I see | 09:17 |
| joseo | It's a pitty | 09:18 |
| === herzel [i=herzel@gateway/tor/x-c1976f286381567c] has joined #bzr | ||
| GaryvdM | joseo: What problems are you having? | 09:18 |
| joseo | GaryvdM: this -> bzr: ERROR: Generic path error: '/.bzr': error w/ stat: 550 CWD command failed. "/.bzr": Permission denied.) | 09:20 |
| joseo | 09:20 | |
| GaryvdM | What did you do to get there? | 09:21 |
| GaryvdM | e.g. what command? | 09:21 |
| joseo | bzr push ftp://user:pwdf@ftp.drivehq.com --use-existing-dir | 09:22 |
| james_w | joseo: that will push to the root of the server, you probably want to push to a subdir. | 09:22 |
| joseo | I know | 09:23 |
| james_w | bzr push ftp://user:pwd@ftp.../home/user/bzr/ or similar | 09:23 |
| joseo | but no difference | 09:23 |
| lapthrick | jelmer: hoho, you have fixed that push bug I see? | 09:23 |
| joseo | bzr push ftp://joorce:gandalf@ftp.drivehq.com/PublicFolder/CocoaNotepad --use-existing-dir | 09:24 |
| joseo | this the desired command but no way | 09:25 |
| GaryvdM | joseo: have you tried using another ftp client to see if you have permission to write there with another file? | 09:25 |
| lapthrick | is there something like bzr missing, but for checkouts? | 09:26 |
| lapthrick | as in, I want to know how out-of-date my checkout is | 09:26 |
| Lo-lan-do | I was wondering about that, and didn't find anything. | 09:26 |
| lapthrick | Lo-lan-do: bueh :\ | 09:27 |
| lapthrick | it'd be a good tool for those of us who only follow someone else's branches | 09:27 |
| Lo-lan-do | Yeah. I turned my checkout into a branch for precisely that reason. | 09:27 |
| joseo | GaryvdM: Have to go, thanks for the help | 09:28 |
| james_w | can you bzr missing <master> ? | 09:28 |
| GaryvdM | ok - np | 09:28 |
| lapthrick | james_w: are you asking me? | 09:28 |
| === Lo-lan-do tries | ||
| lapthrick | mathrick@hatsumi:~/.bazaar/plugins/svn$ bzr missing http://people.samba.org/bzr/jelmer/bzr-svn/0.4/ | 09:30 |
| lapthrick | Branches are up to date. | 09:30 |
| lapthrick | I guess not | 09:30 |
| james_w | ah, no it will compare the branch to itself I guess. | 09:30 |
| lapthrick | Lo-lan-do: but branches are a huge waste of space if you don't intend to hack the code, just follow it | 09:30 |
| james_w | what would be cleanest, a flag to checkout, a flag to update, or a new command? | 09:30 |
| Lo-lan-do | lapthrick: I know, I know, but in the case of bzr-svn, it's not much space anyway, I guess. | 09:31 |
| Lo-lan-do | 5 MB instead of 800 KB I can afford that. | 09:31 |
| lapthrick | yeah, I guess | 09:31 |
| lapthrick | but there were biggest checkouts I did | 09:32 |
| lapthrick | james_w: how about bzr status? | 09:32 |
| lapthrick | I think it'd make sense to have it there | 09:32 |
| james_w | status could be good too. | 09:32 |
| lapthrick | james_w: are you gonna hack it in? :) | 09:32 |
| lapthrick | (go james_w!) | 09:33 |
| === pbor still has problems with bzr-svn... I am not able to push to the svn repo | ||
| Lo-lan-do | Then make it "status -u", please, in order not to *require* net connection | 09:33 |
| Lo-lan-do | pbor: You're not alone :-) | 09:33 |
| pbor | paolo@murdock:~/bzr/gedit-dev$ bzr merge svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk | 09:33 |
| pbor | Nothing to do. | 09:33 |
| pbor | paolo@murdock:~/bzr/gedit-dev$ bzr push svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk | 09:33 |
| pbor | bzr: ERROR: These branches have diverged. Try using "merge" and then "push". | 09:33 |
| pbor | it refuses to commit because there is stuff to merge but it refuses to merge because there is nothing to merge | 09:34 |
| lapthrick | Lo-lan-do: -u? | 09:34 |
| Lo-lan-do | lapthrick: Like in svn | 09:34 |
| lapthrick | Lo-lan-do: also, I'd make -u *not* check that, and do otherwise | 09:34 |
| Lo-lan-do | Or --somethingelse, I don't care | 09:34 |
| lapthrick | so -u would be "unconnected" | 09:34 |
| Lo-lan-do | "svn status -u" means check for remote changes too, so I don't think it would be a good idea to reuse the same option with an opposite meaning | 09:35 |
| lapthrick | Lo-lan-do: then --offline | 09:35 |
| lapthrick | I personally think it's a good default to do it | 09:36 |
| Lo-lan-do | Hm. The default for status in branches is to work offline, so I'd rather have the same behaviour in checkouts. | 09:37 |
| lapthrick | does status in branches ever result in network connections? | 09:37 |
| fkumro | after i create a personal branch (bzr branch), edit a file, commit it, do I need to use bzr merge to get the file to the server or push? | 09:37 |
| Lo-lan-do | lapthrick: No | 09:37 |
| lapthrick | fkumro: push | 09:37 |
| fkumro | thanks | 09:37 |
| lapthrick | fkumro: though a merge could be also needed before you can push, if the upstream has done something you didn't merge yet | 09:38 |
| lapthrick | Lo-lan-do: but then, checkouts pretty much by definition are networked whilst branches aren't | 09:38 |
| fkumro | very true, I'll have to remember to do that so I dont run into issues. | 09:39 |
| lapthrick | I think it makes perfect sense to include that for checkouts | 09:39 |
| lapthrick | fkumro: it will tell you when you do :) | 09:39 |
| asabil | pbor: try to pull ? | 09:39 |
| fkumro | lapthrick: when I try to push and it needs to merge it will tell me that? Seems too easy :-P | 09:39 |
| lapthrick | asabil: but it's still very odd that bzr merge won't do anything | 09:39 |
| Lo-lan-do | bzr status doesn't check for missing changes. bzr missing does. Please don't change the behaviour of bzr status. | 09:40 |
| lapthrick | fkumro: yeah, it won't let you push to a diverged branch | 09:40 |
| lapthrick | Lo-lan-do: but bzr missing ./mycheckout will check missing for the branch it's a checkout for, not for checkout itself, so you can't overload it to check for checkout's status too | 09:41 |
| lapthrick | Lo-lan-do: I really don't see anything bad about defaulting to networked ops for checkouts, they do that already anyway | 09:41 |
| pbor | asabil: do you mean pull from the svn repo? shouldn't merge imply that? (trying anyway in the mean time) | 09:42 |
| fkumro | one more question for everyone. I'm only playing around with simple directory layouts but I have my levels of directories on my projects at home. If I go into the root and execute "bzr init ." then "bzr add" and then commit will bzr recursively add all the directories below root? | 09:42 |
| asabil | pbor: pull and merge are slightly different, but still your case seems really weird | 09:43 |
| pbor | asabil: didn't help... | 09:43 |
| pbor | :( | 09:43 |
| lapthrick | fkumro: yes | 09:44 |
| asabil | pbor: which version of bzr ? | 09:44 |
| pbor | asabil: I just pulled from svn, made a change, committed it and now I want to push it... it's not like I was doing some crazy stuff | 09:44 |
| lapthrick | fkumro: if you want to keep different things in separate branches, you might consider making it a repository (though it mostly makes sense when there are branches that would be able to share stuff, as repos make them able to reuse identical data) | 09:45 |
| pbor | asabil: 0.90.0 | 09:45 |
| asabil | hmm, really weird | 09:46 |
| fkumro | lapthrick: That's something I have to read into more tonight before moving my code over. I will probably be back here asking more questions about that exact topic. | 09:46 |
| pbor | asabil: do you successfully use bzr with a gnome svn module? | 09:47 |
| asabil | pbor: https://lists.ubuntu.com/archives/bazaar/2007q2/026497.html | 09:48 |
| asabil | pbor: I don't have a gnome svn account, so I cannoy push | 09:48 |
| asabil | I pulled already without any problem | 09:48 |
| pbor | asabil: yeah, that message looks like the same issue | 09:49 |
| pbor | pulling works | 09:49 |
| asabil | looks like a bug to me | 09:49 |
| pbor | yeah... /me digs in launchpad | 09:50 |
| lifeless | moin | 09:50 |
| GaryvdM | Hello lifeless | 09:51 |
| vila | hi lifeless | 09:51 |
| asabil | pbor: can you try the latest bzr and bzr-svn ? | 09:51 |
| === sverrej [n=sverrej@ti0125a340-0748.bb.online.no] has joined #bzr | ||
| pbor | asabil: well, I hoped that gutsy had stuff recent enough :) | 09:52 |
| pbor | asabil: but ok, I'll try latest and greatest | 09:52 |
| GaryvdM | lifeless: Do you know a easy way to run a lsprof on olive-gtk? | 09:52 |
| asabil | 0.91 is not in gutsy I guess | 09:52 |
| Lo-lan-do | 0.91 is out? | 09:53 |
| james_w | asabil: bzr-svn 0.4.2 is a more significant change than bzr 0.91. | 09:53 |
| asabil | candidate | 09:53 |
| james_w | Lo-lan-do: not as yet I believe. | 09:53 |
| Lo-lan-do | Oh. Right. | 09:53 |
| asabil | james_w: bzr-svn 0.4.2 works with 0.90 ? | 09:53 |
| asabil | pbor: try to update only bzr-svn then | 09:54 |
| === sverrej [n=sverrej@ti0125a340-0748.bb.online.no] has joined #bzr | ||
| lifeless | GaryvdM: hmm | 09:54 |
| lifeless | GaryvdM: if the --lsprof command doesn't work well | 09:54 |
| lifeless | GaryvdM: then I'd use the bzrlib.lsprof module directly around the function to profile | 09:54 |
| pbor | asabil: mmm... how do I install bzr-svn without changing bzr? | 09:55 |
| asabil | system wide ? or for the user only ? | 09:55 |
| === rml [n=Skippy@78.32.35.169] has joined #bzr | ||
| === Mez_ [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| GaryvdM | lifeless: I was thinking, maybe I could make olive-gtk a plugin command.... | 09:56 |
| pbor | asabil: well, if possible I'd like to test it locally | 09:56 |
| GaryvdM | Would that work> | 09:56 |
| GaryvdM | s/>/? | 09:56 |
| lifeless | GaryvdM: I'd guess so; bzr viz already is | 09:57 |
| GaryvdM | Cool | 09:57 |
| lifeless | GaryvdM: so you could try 'bzr --lsprof viz' and see how well it works | 09:57 |
| GaryvdM | I've been useing that lots... | 09:57 |
| asabil | pbor: then download the latest release from http://samba.org/~jelmer/bzr/bzr-svn-0.4.3.tar.gz and untar it to ~/.bazaar/plugins | 09:58 |
| GaryvdM | I've managed to get bzr viz bzr.dev from 30 sec to 2.5 sec | 09:58 |
| GaryvdM | Lots and lots of profiling | 09:58 |
| lifeless | cool | 09:58 |
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| GaryvdM | Now I want to look at Bug 70463 | 09:59 |
| ubotu | Launchpad bug 70463 in bzr-gtk "olive slow when used in bound branch" [Medium,Confirmed] https://launchpad.net/bugs/70463 | 09:59 |
| asabil | pbor: after untarring it, you would probably want to rename the folder to svn (so that it is a valid python package) | 09:59 |
| asabil | also don't forget to uninstall the installed system wide bzr-svn just in case | 09:59 |
| lifeless | mwh: so how did it look ? | 10:00 |
| asabil | pbor: how did it go ? | 10:06 |
| === kiko-fud is now known as kiko | ||
| pbor | asabil: trying... the push seems to be going through, albeit slowly | 10:06 |
| asabil | yeah, bzr-svn is quite slow unfortunately :/ | 10:07 |
| pbor | UGH | 10:07 |
| pbor | http://svn.gnome.org/viewcvs/gedit/trunk/ | 10:07 |
| pbor | it touched *every* file | 10:08 |
| asabil | :/ | 10:08 |
| Lo-lan-do | Probably only the properties | 10:09 |
| asabil | 5900 revisions ... did you manage to check it out without eating 4 Gb of memory ? | 10:10 |
| pbor | Lo-lan-do: does that mean that it may have screwed up all svn properties? | 10:10 |
| mwh | lifeless: not great :/ | 10:10 |
| Lo-lan-do | I don't think so, it probably just added bzr:* revisions | 10:10 |
| Lo-lan-do | Er, properties | 10:10 |
| pbor | asabil: heh... that was a pain, thanks to jelmer suggestions we figured it out: | 10:11 |
| pbor | r=$1 | 10:11 |
| pbor | while [ $r -ne $2 ] ; do | 10:11 |
| pbor | bzr pull -r$r svn+ssh://pborelli@svn.gnome.org/svn/gedit/trunk | 10:11 |
| pbor | r=$(( $r + 100 )) | 10:11 |
| pbor | done | 10:11 |
| mwh | lifeless: most of the "getting data out of bzrlib" steps took 1.5-2x as long on the packs repo | 10:11 |
| mwh | so not hideous, but not very good either | 10:11 |
| pbor | asabil: and yes, it took a looooong time :) | 10:12 |
| === mwh --> pub | ||
| asabil | pbor: it's a memory leak in python-svn :/ not really bzr's fault | 10:12 |
| pbor | asabil: yeah, I know | 10:13 |
| pbor | asabil: that's why I had to do it 100 revisions at a time | 10:13 |
| asabil | that's a smart trick :) | 10:13 |
| pbor | asabil: however it's not the only thing that is slow... | 10:13 |
| asabil | yep, bzr-svn needs some profiling I guess | 10:14 |
| pbor | asabil: I am trying to push a copy of the repo to my gnome.org ~ dir and it is taking forever | 10:14 |
| Lo-lan-do | I can branch ~4800 revisions from the Gforge svn without such a trick, but it does take some time. | 10:14 |
| pbor | Lo-lan-do: how many gigs of memory do you have :) | 10:14 |
| Lo-lan-do | 1 | 10:14 |
| Lo-lan-do | But I expect gforge may be smaller than gedit | 10:15 |
| === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr | ||
| pbor | asabil: the push I am tryng to do is with sftp... | 10:15 |
| Lo-lan-do | 44 MB | 10:15 |
| pbor | Lo-lan-do: 5900 revisions here | 10:15 |
| Lo-lan-do | Ah, no, not even that, 37 MB | 10:16 |
| pbor | 126M gedit-dev/ | 10:16 |
| Lo-lan-do | I think that's where you beat me :-) | 10:16 |
| pbor | mmm... wait that is with built stuff | 10:16 |
| pbor | clean 87M | 10:17 |
| pbor | is there a way to compress all local commits in a single revision for svn? | 10:20 |
| pbor | e.g: I hack on feature X do 10 small commits and fixups in my branch | 10:21 |
| pbor | but then I just want to push it as a single patch for the 'upstream' repo | 10:21 |
| Lo-lan-do | Maybe doing it in another branch, then merging to your gateway branch, then pushing that gw branch to svn | 10:22 |
| Lo-lan-do | (Not tried myself, since bzr-svn still doesn't want to let me push to svn) | 10:22 |
| pbor | Lo-lan-do: did you update to the latest bzr-svn? that did the trick for me | 10:23 |
| Lo-lan-do | I run on the latest, but I have another bug. | 10:23 |
| GaryvdM | pbor: You can uncommit x n and then commit | 10:24 |
| GaryvdM | Ah - uncommit has -r so you can uncommit -r (starting revision) and then commit | 10:25 |
| pbor | GaryvdM: ugh, sounds ugly :) | 10:25 |
| asabil | pbor: why collapse the commits ? | 10:26 |
| GaryvdM | Please do it in a branch.... | 10:26 |
| asabil | you lose the ability to make quite orthogonal commits | 10:26 |
| lapthrick | argh | 10:26 |
| lapthrick | now that jelmer fixed that push but, I'm running into branches diverged thing myself | 10:26 |
| lapthrick | *bug | 10:26 |
| asabil | pbor: can I get you to give bzr record a try ? | 10:27 |
| lapthrick | pbor: you say bzr pull fixed it for you? | 10:27 |
| lifeless | mwh: ok, can you give me some timings and operations you were testing with | 10:27 |
| lapthrick | mine says no revisions to pull | 10:27 |
| pbor | asabil: because with a local repo I commit very often but that makes the history hard to follow... if I hack, commit, fix a typo that prevents compilation fix it, commit, there is no use for that to go in the public history | 10:28 |
| lapthrick | lifeless: is there some way I can make bzr bail out on errors? | 10:28 |
| pbor | lapthrick: using the latest bzr-svn fixed it | 10:28 |
| lapthrick | pbor: I thought I was using the latest :( | 10:28 |
| asabil | pbor: then you can think about writing a bzr plugin ? | 10:28 |
| pbor | asabil: what is bzr record? | 10:29 |
| lapthrick | mathrick@hatsumi:~/.bazaar/plugins/svn$ bzr update | 10:29 |
| lapthrick | Tree is up to date at revision 718. | 10:29 |
| lapthrick | pbor: what branch do you pull from, 0.4 or trunk? | 10:29 |
| asabil | pbor: a plugin I wrote to create orthogonal patches from a bzr tree :D | 10:30 |
| pbor | lapthrick: I used the last released tarball 0.4.3 | 10:30 |
| pbor | asabil: sounds nice! | 10:30 |
| asabil | pbor: you can grab it from the bzr plugins page | 10:30 |
| pbor | ok | 10:31 |
| lapthrick | pbor: bummer, that I can't use because I rely on fixes from r716 | 10:31 |
| lapthrick | asabil: ooh, sounds nice | 10:31 |
| pbor | lapthrick: yay, for bleeding edge software :P | 10:31 |
| lapthrick | that's really useful for pushing upstream | 10:31 |
| lifeless | lapthrick: we do bail on errors | 10:32 |
| lapthrick | lifeless: err, yes, bad phrasing, I'd like it to bail when it says branches have diverged | 10:32 |
| asabil | lapthrick: it is still very sketchy, I wrote it because we use bzr at work and we need to submit patches upstream | 10:32 |
| lifeless | lapthrick: what do you mean precisely; do you mean a different return value to the shell ? | 10:33 |
| pbor | asabil: add a --bugzilla option that attaches the patches in bugzilla and I am sold :) | 10:33 |
| lifeless | lapthrick: and from what command | 10:33 |
| === LeoNerd [n=leo@cel.leonerd.org.uk] has joined #bzr | ||
| asabil | pbor: that would be easy to do, but what I want is a --interactive to the commit commands | 10:34 |
| asabil | so that you can select exactly which hunks to commit | 10:34 |
| asabil | (yes I used darcs before ...) | 10:34 |
| lapthrick | lifeless: I would like something I can break on in PDB or similar | 10:35 |
| lapthrick | bzr bzr-pokersource:2902/> push svn+https://beta.aimido.de/svn/src2/branches/mathrick/pokersource | 10:35 |
| lapthrick | These branches have diverged. Try using "merge" and then "push". | 10:35 |
| lapthrick | lifeless: I mean I'd like to catch the moment when it decides they have diverged | 10:35 |
| === pbor wonders if bzr squash to merge commits in just one commit would doable as a plugin | ||
| === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr | ||
| lifeless | lapthrick: oh hmm, edit bzrlib/builtins.py perhaps ? | 10:37 |
| lifeless | lapthrick: or have you not tried 'BZR_PDB=1 bzr push' | 10:37 |
| === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr | ||
| lapthrick | nope | 10:37 |
| lapthrick | hmm, that doesn't really tell me which part of bzr-svn decides they have diverged | 10:39 |
| === marianom [n=marianom@ubuntu/member/marianom] has joined #bzr | ||
| === cprov is now known as cprov-afk | ||
| === pbor keeps on asking since it worked out well so far... | ||
| pbor | can I make bzr-svn do not commit .bzrignore files in svn? | 10:53 |
| === Demitar [n=demitar@c-212-031-182-147.cust.broadway.se] has joined #bzr | ||
| === Mez_ is now known as Mez | ||
| GaryvdM | add .bzrignore to .bzrignore and remove from tree | 10:54 |
| pbor | GaryvdM: but if I remove it from the tree, then when branching with bzr it will not be pulled right? | 10:55 |
| === Mez_ [n=mez@ubuntu/member/mez] has joined #bzr | ||
| GaryvdM | Yhea | 10:56 |
| pbor | I wonder if bzr-svn could special case that | 10:56 |
| lifeless | lapthrick: ah, so now we get closer:) | 10:56 |
| lifeless | lapthrick: bzr-svn exposes the regular bzr api | 10:56 |
| lapthrick | lifeless: yeah, I even for it to stop in branch.py | 10:57 |
| lifeless | lapthrick: which pull can use | 10:57 |
| lapthrick | s/for/got/ | 10:57 |
| lifeless | are you using svn-push? I think you are meant to | 10:57 |
| lapthrick | lifeless: no, svn-push is only meant to be used if you need to create a new branch on the svn side | 10:57 |
| lifeless | oh | 10:58 |
| GaryvdM | It would be cool if bzr-svn could translate betweem bzr ignore and svn ignore... | 10:58 |
| lifeless | are you sure ? :) | 10:58 |
| lapthrick | lifeless: that's what all the docs say, so pretty sure, yes | 10:58 |
| lifeless | ok | 10:58 |
| lifeless | so anyhow, the decision about variance is quite simple | 10:59 |
| lifeless | given a graph for the left branch and for the right branch | 10:59 |
| lifeless | either the tip of the left branch is in the right branch's graph, or its not | 10:59 |
| lifeless | if it is, the right branch can be pushed onto the left branch | 10:59 |
| lifeless | if it is not, it errors | 10:59 |
| lifeless | so in bzrlib api terms | 10:59 |
| lapthrick | yeah, I can see the line where it raises DivergedBranches | 11:00 |
| lapthrick | I just need to understand what exactly it checks | 11:00 |
| lifeless | bzrlib.branch.Branch.open('svn://...').last_revision() in bzrlib.branch.Branch.open('.').repository.get_ancestry([bzrlib.branch.Branch.open('.').last_revision()] ) | 11:00 |
| lifeless | IIRC | 11:00 |
| lifeless | possibly get_ancestry takes a revid not a list of revids | 11:01 |
| lapthrick | if not other.repository.get_graph().is_ancestor(self.last_revision(), | 11:01 |
| lapthrick | stop_revision): | 11:01 |
| lapthrick | if self.repository.get_graph().is_ancestor(stop_revision, | 11:01 |
| lapthrick | self.last_revision()): | 11:01 |
| lapthrick | return | 11:01 |
| lapthrick | raise DivergedBranches(self, other) | 11:01 |
| lapthrick | bah | 11:01 |
| lapthrick | not pretty | 11:01 |
| lifeless | so the inner if there checks for 'this branch has already been pushed here' | 11:03 |
| lifeless | the outer checks for 'someone else has pushed here before you and you should merge from them before pushing' | 11:03 |
| lapthrick | http://codebrowse.launchpad.net/~jelmer/bzr-svn/0.4/annotate/jelmer%40samba.org-20070925134348-1bsc948sqqmevhvh?file_id=svnbranch.py-20051017135706-11c749eb0dab04a7#L343 | 11:04 |
| lapthrick | here it is a bit nicer | 11:04 |
| lapthrick | lifeless: I see | 11:04 |
| lapthrick | lifeless: so foo.is_ancestor(bar) checks if bar is ancestor of of foo? | 11:05 |
| lapthrick | or the other way around? | 11:06 |
| lifeless | graph.is_ancestor(foo, bar) is True if bar is reachable from foo in graph | 11:06 |
| lifeless | that is, if foo is an ancestor of bar | 11:07 |
| === asak [n=alexis@201-13-27-139.dsl.telesp.net.br] has joined #bzr | ||
| === schierbeck [n=daniel@disko.egmont-kol.dk] has joined #bzr | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!