=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
ubotu | New bug: #178695 in bzr-cvsps-import "Problem when trying to import CVS module" [Undecided,New] https://launchpad.net/bugs/178695 | 08:41 |
---|---|---|
* ddaa starts looking at bzr-git | 08:48 | |
ddaa | > stgit is used to provide python parsing of the output of git commands. | 08:48 |
ddaa | gack! pyarch flashback! | 08:48 |
``Cube | has anyone received my mail? | 08:49 |
``Cube | ddaa: ? | 08:49 |
ddaa | Is that the quick hack it looks like, or is this the officially blessed way to bind to git? | 08:49 |
ddaa | ``Cube: using CLI spawning/parsing as a library binding is evil. | 08:50 |
``Cube | huh? | 08:50 |
``Cube | just asked about the icon mail | 08:50 |
``Cube | I didn't get any feedback yet | 08:50 |
ddaa | dunno what you asked about, I just got in. This was an unrelated comment. | 08:51 |
``Cube | ah ok :D | 08:51 |
``Cube | well, so I'll ask again: I sent a mail with icons | 08:51 |
``Cube | did you get it? | 08:52 |
``Cube | some days ago | 08:52 |
ddaa | I have 4764 unread mails in my bzr folder. | 08:52 |
``Cube | WOO | 08:52 |
``Cube | lol nice | 08:52 |
``Cube | could you search for mine? | 08:53 |
ddaa | subject? | 08:53 |
``Cube | one second, oki? | 08:53 |
``Cube | Introduction + Bazaar Icon Tango Remake | 08:53 |
ddaa | There's such an email | 08:54 |
ddaa | with one giant png that collates a bunch of icon | 08:54 |
``Cube | heh ;) | 08:54 |
``Cube | yea | 08:54 |
``Cube | thanks it | 08:54 |
``Cube | *that's it | 08:54 |
ddaa | not really usable as is | 08:54 |
``Cube | hmm :S | 08:55 |
``Cube | it was just a propose | 08:55 |
``Cube | hmm, you don't like it, ok | 08:55 |
``Cube | looks like its not gonna pass | 08:55 |
ddaa | I am in no position to make a judgement about it. | 08:56 |
ddaa | It just looks kind of weird to me that you submit tango icons to upstream. Shouldn't this be packaging in the tango theme package, instead of bzr? | 08:56 |
``Cube | well, I wanted to replace the current icons with tango icons | 08:56 |
``Cube | on launchpad, the webpage and so on | 08:57 |
ddaa | ``Cube: Also, all the Canonical folks are on holiday ATM, so you should wait until January for an authoritative reply. | 08:57 |
``Cube | oh, ok | 08:57 |
``Cube | but you don't think they'll pass it? | 08:58 |
``Cube | by the way, the 16x16 isn't ready yet | 08:58 |
ddaa | They sure look nice. My private opinion is that they are too low-contrast for use as the main icons. But they are a great fit to tango-like themes. | 08:59 |
ddaa | But it's only my private opinion, the people in charge may very well think differently. | 09:00 |
``Cube | oh ok | 09:00 |
``Cube | I mean, I can change them completely | 09:00 |
ddaa | couple of things I do like | 09:00 |
``Cube | I just tried to make them look close to the original ones | 09:00 |
ddaa | is the lack of drop-shadow under the arrow, and the square incoming road. | 09:01 |
ddaa | Please do not change them because of my feedback. Wait for authoritative feedback. | 09:01 |
``Cube | heh ;) ok sure | 09:02 |
``Cube | well, are the canonical very... | 09:02 |
``Cube | lets say | 09:02 |
``Cube | professional? | 09:02 |
``Cube | or do they accept lil mistakes at the beginning | 09:02 |
``Cube | and similar stuff? | 09:02 |
ddaa | Being professional and being welcoming to new community contributors do not have to be mutually exclusive. | 09:03 |
``Cube | hmm, you're right... | 09:03 |
``Cube | well ok, thanks a lot, ill wait until they come back | 09:03 |
``Cube | in JAN | 09:03 |
``Cube | ehm, do you have someones IM? | 09:04 |
``Cube | I'd like to contact them personally | 09:04 |
``Cube | because, if there are so many mails coming in | 09:04 |
``Cube | mine will probably go under | 09:04 |
ddaa | That's okay. They know how to do deal with large amount of email. I'm sure you'll receive some attention. | 09:04 |
ddaa | Nagging is not a good idea at first. You did the right thing by posting to the mailing list and by asking here. | 09:05 |
ddaa | BTW, this crowd tend to prefer pure-text email rather than HTML. | 09:06 |
ddaa | Just for the future. | 09:06 |
``Cube | hmm ok | 09:06 |
``Cube | thanks | 09:06 |
``Cube | but someone with pure-text, can he receive my mails at all? | 09:07 |
ddaa | sure | 09:07 |
ddaa | they include a text/plain mime part. | 09:07 |
``Cube | ah, ok | 09:08 |
ddaa | they do not look optimal (too many blank lines) but they are perfectly readable. | 09:08 |
``Cube | oh yes, heard about that blank line issue somewhere | 09:08 |
lifeless | beuno: there are plugins for eclispe and visual studio for bzr :)) | 09:49 |
ddaa | hey lifeless | 09:50 |
lifeless | hey ddaa, happy xmas stuff | 09:54 |
ddaa | thank, happy yours | 09:54 |
* ddaa had enough christmas for one year | 09:54 | |
i386 | lifeless: :) | 10:01 |
i386 | merry xmas and all that crap :) | 10:02 |
lifeless | i386: :) | 10:02 |
* ddaa went out to ask about binding in #git | 10:03 | |
ddaa | this really gives me very strong flashbacks of GNU Arch. | 10:03 |
ddaa | I hope it's just my personal prejudice. | 10:04 |
lifeless | git is the new arch | 10:04 |
ddaa | I'm fearing that much. | 10:04 |
ddaa | This notion scares the hell outta me. | 10:04 |
lifeless | libgit is internal only | 10:05 |
lifeless | I investigated this when starting bzr-git | 10:05 |
lifeless | anyhow, I'm not here ;), Just checking mail after 5 das without :) | 10:05 |
Peng | Git is the new Arch? | 10:10 |
ddaa | Apparently they seem to have this notion that "writing a library interface" is something you can slap over an existing codebase designed to be CLI-driven. | 10:16 |
ddaa | Although my experience in this respect is limited to tla, I believe it's usually nowhere near that simple. | 10:16 |
ddaa | Small things like error reporting and resources handling you need not worry much about in small one-off processes are critical to making a good library API. And a huge pain in the ass to retrofit. | 10:17 |
ddaa | Then "since nobody has bothered to do it, it's probably not all that useful"... | 10:18 |
ddaa | GNU Arch had a way to twist people perceptions. I'm scared that similar things might be at work in the git community. | 10:19 |
ddaa | Not, all of what I just said is my just my personal opinion. | 10:20 |
ddaa | And not all that informed at that. | 10:20 |
ddaa | It seems that git failure modes are indeed consistent with my expectations... | 10:47 |
ddaa | "Fails in mysteriously arcane way for trivial mistakes." | 10:47 |
Peng | Hmm. Bzr and hg are written as libraries. That's kind of an advantage, huh? | 10:48 |
ddaa | Trying to clone from something that's is not a git repo yields "fatal: Not a valid object name HEAD". That's git-speak for "Not a branch." | 10:48 |
Peng | So they write error messages in code. What does that have to do with librarification? :) | 10:49 |
ddaa | tla tended to have the same error reporting issues | 10:49 |
ddaa | things written to be a bunch a scripts seem to tend to suck at propagating error conditions and displaying meaningful context-sensitive messages. | 10:50 |
ddaa | So, then tend to resort to displaying low level errors to the user. | 10:51 |
Peng | Is doing it well in C harder than in Python? | 10:51 |
ddaa | It's not really a matter of language. | 10:51 |
Peng | Ok. | 10:52 |
ddaa | Rather a matter of how people think about their software. | 10:52 |
ddaa | Though, good error reporting is much harder in C than in Python. Exception was one of the great advances in programming languages that occured after C. | 10:55 |
ddaa | But it seems good C programmers are kind of used to setting up whole frameworks to give C things like exceptions, managed memory and run-time polymorphism. And I assume that git programmers are good C programmers. | 10:56 |
fullermd | All that stuff isn't important, though. Fast is all that matters. | 11:19 |
ddaa | fullermd: always the troll, aren't you? :) | 11:20 |
fullermd | I'm trying to reach my quota so I can leave my bridge for a few hours today. | 11:21 |
* ddaa gives fullermd a red herring | 11:21 | |
* fullermd chops down a tree with it. | 11:21 | |
ddaa | in monkey island, that used to make the bridge troll happy | 11:21 |
mathrick | ddaa: oh man, tla was horrible | 11:58 |
mathrick | "ERROR: botched assertion (125)" | 11:58 |
mathrick | though it made me learn the word "botched", so it was useful in a way | 11:59 |
=== GaryvdM_ is now known as GaryvdM | ||
ddaa | that one usually meant some form of data corruption :) | 12:03 |
ddaa | in bzr you'd get a traceback in similar cases, which is only marginally better | 12:04 |
acuster | Hey all, with bzr-svn what's the difference between an initial 'bzr branch' and a 'bzr co'? | 12:17 |
GaryvdM | acuster: branch can create a branch without a working tree. checkout w | 12:27 |
GaryvdM | checkout allways creates a branch with a working tree | 12:28 |
* fullermd blinks. | 12:28 | |
acuster | okay, that makes sense | 12:28 |
GaryvdM | checkout is also used to create a working tree for a branch that does not have a working tree | 12:28 |
fullermd | Not to me it doesn't... is bzr-svn really so different from bzr? | 12:28 |
GaryvdM | no | 12:28 |
acuster | do you know what format I should init-repo with for bzr-svn? | 12:28 |
fullermd | Then the difference is that branch creates a branch, and co creates a checkout. | 12:29 |
GaryvdM | Am I wrong fullermd? | 12:29 |
acuster | fullermd, that may be entirely true but pedagogically, it's useless | 12:29 |
ddaa | Ahem | 12:29 |
ddaa | Okay, so a checkout (heavy checkout) is just a branch. | 12:29 |
fullermd | Grr. No it's not, it's a checkout. | 12:30 |
* fullermd stabbies the branch. | 12:30 | |
ddaa | Except it's "bound" to a master, and when committing to a checkout, changes are automatically pushed to the master, atomically. | 12:30 |
GaryvdM | Checkout = branch + working tree? | 12:30 |
fullermd | A branch gives you an independent branch to work on. | 12:30 |
dato | GaryvdM, nope | 12:30 |
fullermd | A checkout lets you work on the branch you point it at. | 12:30 |
bob2 | acuster: something with rich-root support (--rich-root or --rich-root-pack) | 12:30 |
ddaa | GaryvdM: I am afraid you are confused. | 12:30 |
acuster | bob2, thanks | 12:30 |
GaryvdM | oh | 12:31 |
ddaa | GaryvdM: what you call a checkout here is a lightweight checkout. | 12:31 |
ddaa | hello bob2 | 12:31 |
ddaa | long time no see | 12:31 |
bob2 | he ddaa | 12:31 |
bob2 | er, hey. | 12:31 |
ddaa | acuster: so, with bzr-svn, you only really want to use "bzr checkout" to create a branch that you will use only to merge your bzr work into the svn repository. | 12:32 |
ddaa | note, that you can turn a "checkout" into a "branch" using "bzr unbind", and conversely using "bzr bind". | 12:33 |
ddaa | (those are fairly obscure commands, but they are useful to illustrate that a heavyweight checkout is just a branch with some special behaviour) | 12:34 |
fullermd | I still say that definition should die a quick and painful death. | 12:36 |
fullermd | It just makes everything more painful. It's not a branch with special behavior, it's a checkout with special behavior. | 12:37 |
dato | and what's a checkout without special behavior? :) | 12:38 |
fullermd | Nothing, any more than an internal-combusion motor without special behavior is anything. Everything has attributes. | 12:38 |
fullermd | Heavy and light are just two different kinds of checkouts with varying attributes and behaviors in edge cases. | 12:38 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
ubotu | New bug: #178722 in bzr "Wrong argument for "bzr log --timezone" triggers internal error" [Undecided,New] https://launchpad.net/bugs/178722 | 13:00 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
ddaa | what's the trick to make "bzr selftest" and pdb go along? | 14:13 |
ddaa | I stuck a "import pdb; pdb.set_trace()" in some method called from a test, but it seems pdb is confused by the test runner. | 14:14 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
ddaa | nevermind | 14:22 |
ddaa | it was my evil psyco plugin | 14:22 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
Poromenos | hi, is there a way to change a commit message? | 14:38 |
dato | Poromenos: nope | 14:39 |
dato | Poromenos: well | 14:39 |
dato | Poromenos: if it's the latest entry, and you haven't pushed to a remote place, you could uncommit, and commit again with a fixed message | 14:39 |
dato | but other than that... | 14:39 |
Poromenos | it's not :/ | 14:39 |
Poromenos | ah well, thanks anyway | 14:40 |
Poromenos | is there a way/need to specify dependencies on a project on launchpad? | 14:41 |
ddaa | ah, I found how to fix the test suite on jam's branch. | 14:48 |
ddaa | It seems that git-fast-import --export-marks=foo now actually changes the foo file instead of just writing to it (hardlink breaking), so it defeats the use of NamedTemporaryFile in the GitBranchBuilder. | 14:49 |
* ddaa grumbles | 14:49 | |
ddaa | that's the kind of stupid shit you get when trying to bind to a CLI | 14:50 |
acuster | grrr 1000 of 7300 and already at 61% cpu, | 14:51 |
``Cube | oh no | 14:51 |
acuster | no way to branch that svn repo | 14:51 |
``Cube | incredible | 14:52 |
acuster | well, let's run until we crash. | 14:52 |
acuster | Does bzr still have know memory leaks? | 14:52 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
jelmer | acuster: It's subversion | 15:02 |
jelmer | There was a huge memory leak in the subversion python bindings | 15:02 |
acuster | hey jelmer | 15:02 |
jelmer | http://subversion.tigris.org/issues/show_bug.cgi?id=3052 | 15:03 |
acuster | thanks | 15:04 |
jelmer | hi ``Cube | 15:13 |
``Cube | hi | 15:13 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
ddaa | jelmer: I think the SvnRaTransport docstring "This implements just as much of Transport as is necessary to fool Bazaar." is a tad bit outdated now :) | 15:44 |
jelmer | heh, good point :-) | 15:44 |
ddaa | was looking for a template transport to define a git:// transport | 15:45 |
jelmer | ah, working on bzr-git ? | 15:48 |
ddaa | just some holiday hacking | 15:50 |
ddaa | best way to benchmark against git would be having a working bzr-git in the first place | 15:52 |
ddaa | also, git is not going to away anytime soon, so it will be useful, and help some ubuntu folks that need to deal with git upstreams. | 15:53 |
jelmer | same here | 16:02 |
jelmer | now that Samba has switched to git, it would be very nice to see a working bzr-git | 16:02 |
fullermd | Think it'll be good and usable in 6 months, say? | 16:04 |
ddaa | there are some unique challenges | 16:04 |
ddaa | such as dealing with git's approach of guessing renames instead of recording them | 16:05 |
ddaa | that assumes the intelligence is in the commands, not in the data. | 16:05 |
ddaa | That clashes quite badly with the bzrlib design. | 16:05 |
fullermd | I just need a planning number, so I can figure out when it'll be time to get samba to switch to the next VCS I want foreign branch support for ;) | 16:05 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
ddaa | It seems quite unlikely to me that anybody would switch away from git to anything but svn or bzr. | 16:06 |
ddaa | depending on where they put the blame for the pain they endured. | 16:07 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
ddaa | what's this me_too thing? | 16:08 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
fullermd | Can't see. too_short. | 16:10 |
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
=== me_too is now known as too_short | ||
=== too_short is now known as me_too | ||
jelmer | ddaa: As long as the plugin always detects renames at the same places, there's no problem :-) | 16:18 |
ddaa | I mean that git has a lot of freedom to evolve their rename-guessing logic | 16:19 |
ddaa | but a bzr-git plugin would be much more constrainted | 16:20 |
fullermd | Yeah. They've got all the time in the world to try and come up with a herustic to figure out the information that the user could just provide at the time :p | 16:21 |
jelmer | ddaa: yup | 16:30 |
jelmer | path tokens ftw! | 16:30 |
ddaa | what's that? | 16:30 |
* ddaa is hopelessly out of touch | 16:30 | |
jelmer | replacement for fileids proposed by robert | 16:30 |
ddaa | gotta be interesting | 16:30 |
jelmer | meant to solve parallel imports and copy tracking | 16:30 |
jelmer | yeah, the idea is very interesting | 16:31 |
jelmer | but it's also quite abstract at this point | 16:31 |
jelmer | http://bazaar-vcs.org/DraftSpecs/PathTokens | 16:31 |
ddaa | I regard git's support for parallel imports a very strong point for them. | 16:33 |
* ddaa reads the spec | 16:33 | |
fullermd | git doesn't lack in strong points. Now, if it lacked a bit more in nuttiness... | 16:34 |
fullermd | The content-addressed storage is certainly a strong point. | 16:35 |
ddaa | I've always felt utterly nonplussed by this. | 16:35 |
fullermd | And I get to like the crypto-hash-as-revid concept better the longer I think of it. | 16:35 |
ddaa | really, we only have identity problems in bzr because of limitations in how we deal with parallel imports. | 16:36 |
ddaa | and content-addressing has some major drawbacks | 16:36 |
fullermd | It's got major advantages too. | 16:37 |
ddaa | as in making it pretty much impossible to have native checkout for foreign repository formats. | 16:37 |
fullermd | Though I see it as fairly orthogonal to the identity issue (at least, insofar as I'd mentally want to take it; file texts) | 16:37 |
ddaa | mh... this spec is pretty light on actual ideas | 16:39 |
ddaa | it's just a problem statement | 16:39 |
ddaa | jelmer: why does bzr-svn uses BOTH BzrDirFormat.register_control_format AND format_registry.register to register SvnRemoteFormat? | 16:42 |
jelmer | Hmm, you're right, that's confusing.. | 16:44 |
ddaa | I guess that means only format_registry is needed, right? | 16:44 |
jelmer | No, I think the first one is for the handling of ".bzr" | 16:45 |
jelmer | s/.bzr/.svn | 16:45 |
jelmer | while the latter is usually a combination of a branch, repository and working tree format | 16:45 |
ddaa | BzrDirFormat.register_control_format(format.SvnRemoteFormat) | 16:45 |
jelmer | "dirstate-with-subtree" | 16:45 |
ddaa | that is not .svn stuff | 16:45 |
jelmer | that's the remote stuff | 16:45 |
jelmer | detecting the control dir happens by checking whether the transport is a SvnRaTransport | 16:45 |
ddaa | right | 16:46 |
jelmer | rather than checking for a .svn directory | 16:46 |
ddaa | but then | 16:46 |
ddaa | format_registry.register("subversion", format.SvnRemoteFormat, | 16:46 |
ddaa | "Subversion repository. ", | 16:46 |
ddaa | native=False) | 16:46 |
jelmer | the format registry bit is just so it appears in the output of "bzr init --help" | 16:46 |
ddaa | ok | 16:47 |
jelmer | and so info knows how to call it | 16:47 |
Poromenos | for some reason i can't branch from https, (launchpad), curl is giving me an error. any ideas? | 16:50 |
ddaa | couple of them | 16:51 |
ddaa | either use the actual http or bzr+http address of the branch | 16:51 |
ddaa | https://code.launchpad.net is just a redirection to http://bazaar.launcphad.net | 16:52 |
Poromenos | it redirects | 16:52 |
Poromenos | hmm | 16:52 |
ddaa | or do not use curl | 16:52 |
Poromenos | i'm not doing it intentionally, bazaar is | 16:52 |
Poromenos | http://bazaar.launchpad.net/gnuhello isn't working | 16:54 |
ddaa | you can use https+urllib:// urls to stop it from using pycurl | 16:54 |
Poromenos | not a branch, actually | 16:54 |
Poromenos | ah | 16:54 |
ddaa | or you can uninstall pycurl if nothing else is using it on your system | 16:54 |
Poromenos | i don't think anything is, i'll try that, thanks | 16:54 |
ddaa | btw, this url is indeed not a branch | 16:55 |
Poromenos | as an aside, do you know how i can generate ssl keys? | 16:55 |
Poromenos | yes, but launchpad.net/gnuhello is | 16:55 |
ddaa | check https://code.edge.launchpad.net/~vcs-imports/gnuhello/trunk | 16:55 |
ddaa | you'll see the download URL there | 16:55 |
Poromenos | ah, urllib worked, thanks though | 16:55 |
ddaa | the redirection magic only happens on code.launchpad.net, not on bazaar.launchpad.net | 16:55 |
Poromenos | ah | 16:56 |
ddaa | Poromenos: the command is ssh-keygen, if you are on linux | 16:56 |
ddaa | if you are on Windows, I have no clue. | 16:56 |
Poromenos | i'm on ubuntu, thanks | 16:57 |
ddaa | Poromenos: I'm pretty sure there is extensive documentation about this stuff on help.launchpad.net | 16:57 |
Poromenos | i can't find it, i'm following the tutorial but i couldn't find help on either the tutorial or the ssl keys page | 16:57 |
Poromenos | ssh, i mean | 16:58 |
ddaa | ok | 16:58 |
ddaa | maybe file a bug on launchpad-bazaar then | 16:58 |
ddaa | this sort of thing should be crystal clear. | 16:58 |
Poromenos | i will, thanks | 16:58 |
Poromenos | can i delete a branch after i publish it? | 17:09 |
Poromenos | (on launchpad) | 17:09 |
dato | jelmer: did you see my mail about bzr-plugins? | 17:29 |
jelmer | dato: no that I remember - where did you send it? | 17:29 |
dato | bazaar@ and -maint | 17:30 |
* jelmer has a look | 17:30 | |
GaryvdM | If I ran bzr-gtk's ./setup.py install - is there a way to uninstall? | 17:31 |
Poromenos | can anyone ssh to bazaar.launchpad.net? | 17:52 |
Poromenos | it's not working for me | 17:52 |
ddaa | the shell is disabled | 17:52 |
Poromenos | oh | 17:52 |
Poromenos | temporarily? | 17:52 |
ddaa | permanently | 17:52 |
Poromenos | how do people upload code then? | 17:53 |
ddaa | bzr push | 17:53 |
Poromenos | push where... | 17:53 |
ddaa | to the bzr+ssh url displayed on the branch page of a hosted branch | 17:53 |
Poromenos | that's what's not working | 17:54 |
Poromenos | https://code.launchpad.net/~stavrosk/gmailchecker/main | 17:54 |
ddaa | please paste the bzr command you typed and the output it produced | 17:54 |
Poromenos | bzr push bzr+ssh://stavrosk@bazaar.launchpad.net/~stavrosk/gmailchecker/main | 17:54 |
Poromenos | ssh: connect to host bazaar.launchpad.net port 22: Connection refused | 17:55 |
Poromenos | that's it | 17:55 |
ddaa | meh | 17:55 |
ddaa | indeed, it's down | 17:55 |
dato | Next mirror: | 17:56 |
Poromenos | ah | 17:56 |
dato | As soon as possible | 17:56 |
dato | heh | 17:56 |
Poromenos | i'll wait then, thanks | 17:56 |
Poromenos | can i name a branch? | 17:56 |
Poromenos | i mean in bzr | 17:56 |
Poromenos | probably not, nm | 17:56 |
ddaa | not sure what you mean | 17:56 |
ddaa | you can specify a branch nick that will be recorded in commits | 17:56 |
ddaa | otherwise, the name of a branch is its url | 17:57 |
ddaa | you can change the last past of a branch url on launchpad | 17:57 |
ddaa | "Edit branch details", it's the branch name field. | 17:57 |
Poromenos | i just saw "branch name" on the web interface, but i realized it's what you enter | 17:57 |
Poromenos | yes, thanks | 17:57 |
kripken__ | Since an hour ago I get an error when I try to use bazaar to update my branches on launchpad, "connection refused: please check connectivity and permissions". Any idea how to do that? (it says "try -Dhpss", but that doesn't help) | 18:13 |
ddaa | apparently the ssh server is down | 18:29 |
ddaa | there should be a nagios alarm ringing right now | 18:29 |
foom | are there any speed improvements on the horizon? bzr still (1.0; rich-root-pack source format) seems to be unusably slow (20 minutes, local disk) at making a branch of a 40krev repository. | 18:31 |
luks | the trick is to use shared repositories | 18:32 |
ddaa | right, you don't want to duplicate 40krevs of data anyway | 18:33 |
ddaa | aside from the fs bloat, it does not allow efficient use of the disk caches. | 18:33 |
foom | sure, that's a nice trick when it works. but it doesn't work in all situations, and 20 minutes is *reaaaallly* long. | 18:34 |
jelmer | hi foom | 18:34 |
luks | hm, what are the situations when it doesn't work? | 18:34 |
foom | jelmer: hey there | 18:35 |
foom | luks: branching a remote repository, for example. | 18:35 |
kripken__ | ddaa: thanks for the info | 18:35 |
luks | foom: but you do that only once, and never again | 18:36 |
luks | not such a big problem, IMO | 18:36 |
luks | next time you branch you have most of the data locally | 18:36 |
ddaa | luks: normally, remote branch should be essentially limited by how fast you can pump data off the server. Anything else is a bug. | 18:37 |
ddaa | although it is planned to have shallow branches in the future | 18:37 |
luks | ddaa: yes, but without a shared repository you download it over and over again | 18:37 |
ddaa | so you won't HAVE to pump all the history of the server to make a local branch. | 18:38 |
luks | which is that I guess foom is doing | 18:38 |
luks | er, s/that/what/ | 18:38 |
foom | luks: well, okay, you've got me, if this was the only slow thing in bzr, I guess that might be okay. I dunno if it is or not, it's just the first thing I've tested this go-around. | 18:38 |
foom | and it seems quite unlikely that this would be the only too-slow operation | 18:38 |
ddaa | bzr is certainly not as fast as some of the competition, but using the most recent formats, it should be fast enough. | 18:39 |
ddaa | i.e. the time should be a small multiple of the time of other tools, not orders of magnitudes slower as it used to be. | 18:40 |
ddaa | We think it's more important to have "merge" and "commit" be reliable and easy to use, than to have them run in 0.5 second instead of 2 seconds. | 18:41 |
luks | the most annoying thing to me is not the actual performance, but the startup time | 18:41 |
foom | jelmer: i saw you found the (a?) memory leak in svn python bindings and said you worked around it in bzr-svn; is that workaround expected to not be a full fix? | 18:41 |
jelmer | foom: Yes, it isn't a full fix | 18:41 |
foom | jelmer: okay, cause bzr crashed my machine converting a svn repository by running it out of memory and invoking the OOM killer which killed half the important processes. :( | 18:42 |
jelmer | foom: You need an updated version of the python-subversion bindings for all of the memory leaks to go away | 18:42 |
foom | "hey look, X is taking some memory, let's kill it!". thanks linux...heh | 18:42 |
jelmer | http://subversion.tigris.org/issues/show_bug.cgi?id=3052 | 18:42 |
foom | that's not patched in ubuntu yet is it? | 18:43 |
foom | luks: startup time? | 18:47 |
foom | and...'bzr log -r20000' takes 23s. | 18:54 |
ddaa | jelmer: it seems pretty much impossible to implement a transparent git:// transport | 18:57 |
ddaa | short of reimplementing the client code | 18:57 |
ddaa | common git servers only expose git-fetch-pack and git-peek-remote services | 18:57 |
ddaa | and the former requires a local git dir | 18:58 |
* ddaa finds this frustratingly limited | 18:59 | |
ddaa | yay! git_connect dies on error :( | 19:21 |
jelmer | ddaa: Are you working based on stgit? | 19:24 |
ddaa | jelmer: I'm based on jam's branch | 19:24 |
ddaa | it has no stgit dependency | 19:24 |
ddaa | and right now, I'm staring at the git source itself | 19:24 |
ddaa | and all my fears are confirmed | 19:24 |
jelmer | :-/ | 19:27 |
ddaa | if (protocol == PROTO_GIT) { | 19:27 |
ddaa | /* These underlying connection commands die() if they | 19:27 |
ddaa | * cannot connect. | 19:27 |
ddaa | */ | 19:27 |
ddaa | Also, all the network code seems to assume that sockets and pipe and interchangeable | 19:28 |
ddaa | i.e. forget about windows | 19:28 |
ddaa | At least some of the client code will have to be written from scratch. | 19:29 |
ddaa | or heavily patched. | 19:29 |
jelmer | ddaa: You're writing this in C or Python? | 19:36 |
ddaa | just explorating | 19:36 |
ddaa | Actually, I think I'm going to give up on the transparent transport. | 19:36 |
jelmer | I thought Robert already had a lot of this done | 19:40 |
ddaa | the bzr-git code I see is quite proof-of-concept | 19:40 |
ddaa | and it only works locally | 19:40 |
ddaa | i.e. it does not try to do more than git | 19:40 |
ddaa | which pretty much only knows how to fetch packs over the network, then does everything locally. | 19:41 |
jelmer | ah, ok | 19:45 |
ddaa | unfortunately, I do not think that's an acceptable level of functionality for bzr :( | 19:45 |
ddaa | Hey, bazaar.launchpad.net SFTP server is up again | 20:07 |
piedoggie | I just started reading the user documentation and I am damned impressed. | 21:02 |
piedoggie | it is the clearest description I have ever seen up any revision control system. | 21:02 |
* piedoggie thinks everybody is out at Boxing Day parties | 21:03 | |
eddyMul | hi. I have a bzr branch in my ${HOMEDIR}. I also have another bzr branch in my ${HOMEDIR}/Desktop/vision/proj2/. If I want to graft/merge proj2 to ${HOMEDIR}, should I use `bzr merge`? | 23:39 |
=== Verterok_ is now known as Verterok | ||
Verterok | eddyMul: take a look to the merge-into plugin <https://launchpad.net/bzr-merge-into/>, might be helpful. | 23:50 |
eddyMul | Thanx, Verterok. Will look at it | 23:50 |
eddyMul | Verterok: looks like this is what I'm looking for. There's a bug againts bzr-0.90. Do I need bzr-1.0? | 23:52 |
Verterok | eddyMul: it's seems is broken :( | 23:53 |
Verterok | it's broken against bzr.dev, probably it won't work with 1.0 | 23:54 |
eddyMul | Verterok: when I try merging, it kept complaining "bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified." | 23:55 |
eddyMul | which sounds about right | 23:55 |
eddyMul | when I specify the revisions (there are 5 revs) -r1..5, bzr bombs w/ AssertionErrors | 23:56 |
eddyMul | :( | 23:56 |
Verterok | eddyMul: I just found find-merge-base command, it's part of the hidden commands, take a look to that maybe it can help you to find a base revision to merge | 23:57 |
spiv | eddyMul: you can try "-r0..5" | 23:58 |
spiv | eddyMul: also, there's a "bzr join" command, but it's still experimental. | 23:59 |
Verterok | spiv: thx for the r0..x tip :-) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!