| === dhon__ [n=dhon@60-240-97-109.static.tpgi.com.au] has joined #bzr | ||
| === n2diy_ [n=darryl@wlk-barre-208-103-148-76.dynamic-dialup.coretel.net] has joined #bzr | ||
| keir | sweeeeet, got my compact dictionary building code to work | 12:52 |
|---|---|---|
| === grimeboy [n=grimboy@85-211-243-152.dsl.pipex.com] has joined #bzr | ||
| === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr | ||
| === phanatic_ [n=phanatic@dsl54028306.pool.t-online.hu] has joined #bzr | ||
| === phanatic_ is now known as phanatic | ||
| === pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr | ||
| === jkakar [n=jkakar@204-174-36-45.dhcp802.dsl.ucc-net.ca] has joined #bzr | ||
| === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr | ||
| NfNitLoop | Hmm, when I do 'bzr pull <http-location>' bzr is complaining that paramiko isn't complained, and shows me an sftp url. | 02:29 |
| NfNitLoop | (a saved pull URL that I used long ago.) | 02:30 |
| NfNitLoop | Shouldn't specifying a location argument to pull override that saved location? | 02:30 |
| jelmer | NfNitLoop: hi | 02:30 |
| jelmer | NfNitLoop: that bug that only appeared in 0.90 should be fixed now | 02:30 |
| jelmer | NfNitLoop: no, it will only override if you specify --remember | 02:30 |
| NfNitLoop | jelmer: not even for that run? | 02:31 |
| NfNitLoop | I don't want it to remember... I just want it to pull from a different location. | 02:31 |
| jelmer | yes, it should always use it for that run | 02:31 |
| jelmer | isn't the branch you're pulling to bound by any chance? | 02:31 |
| NfNitLoop | Hmmm. possibly. | 02:31 |
| jelmer | bound to that sftp url, that is | 02:31 |
| === NfNitLoop checks. | ||
| NfNitLoop | I forget where bound info shows up, but I don't see the word "bound" in the results from "bzr info". | 02:32 |
| NfNitLoop | Oh... it does say "checkout of branch sftp://" | 02:32 |
| NfNitLoop | that would be bound, eh? | 02:32 |
| jelmer | yup | 02:32 |
| NfNitLoop | and you can only pull from a bound branch. That should probably give you an error message then. :) | 02:33 |
| jelmer | NfNitLoop: no, you can pull from the http branch | 02:33 |
| NfNitLoop | (er, rather, if you're working from a bound branch, you can only pull from that one.) | 02:33 |
| jelmer | but it will update both the local branch and the branch it's bound to | 02:33 |
| NfNitLoop | jelmer: Aaaaaah. | 02:33 |
| NfNitLoop | so it wasn't failing on the pull... it was just failing on syncing back to the checkout. | 02:33 |
| jelmer | if the error message is confusing, that'd definitely be a bug | 02:34 |
| NfNitLoop | Hmm. It makes sense now. I just hadn't worked with this branch in so long that I didn't realize I'd bound it over sftp. | 02:35 |
| === NamNguyen [n=namnt@cm246.delta196.maxonline.com.sg] has joined #bzr | ||
| NfNitLoop | jelmer: bzr: ERROR: Invalid revision-id {None} in SvnRepository | 02:41 |
| NfNitLoop | :( | 02:41 |
| NfNitLoop | Oh, DUH. | 02:41 |
| NfNitLoop | it would help if I put the new version in my plugins directory. | 02:41 |
| Peng | nir: Yeah, I've noticed the same thing on Linux. I guess it could use os.path.abspath('/tmp') or something? | 02:41 |
| NfNitLoop | jelmer: yay, worked! :) | 02:44 |
| nir | Peng, maybe | 02:44 |
| nir | The test also fail here with OSError - too many open files | 02:47 |
| Peng | Heh. | 02:48 |
| nir | unless I use ulimit to allow more than 256 open files | 02:48 |
| NfNitLoop | jelmer: Though... I'm unable to push: python: /build/buildd/subversion-1.4.2dfsg1/subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `is_canonical(component, clen)' failed. | 02:48 |
| Peng | My ulimit is set to 1024 files, and that freaks out Opera sometimes. Dunno if I can change it, though. | 02:49 |
| nir | Is this the default? | 02:49 |
| Peng | nir: Well, I didn't change it. | 02:49 |
| Peng | Anyway, I'm not on OS X. | 02:49 |
| jelmer | NfNitLoop: if you run with -Dtransport -Dcommit, what are the last few lines in ~/.bzr.log ? | 02:56 |
| NfNitLoop | svn get-latest-revnum | 02:57 |
| NfNitLoop | svn ls -r 0 '''' | 02:57 |
| NfNitLoop | (the first one is repeated 5 times) | 02:57 |
| NfNitLoop | need more? I could e-mail it. | 02:57 |
| jelmer | what url did it connect to ? I don't need the full URL but just the bits after the repository location | 02:59 |
| jelmer | including trailing characters | 02:59 |
| NfNitLoop | there are not bits after the repository location... just the closing ' | 03:00 |
| === troy_s [n=aphorism@d206-116-6-170.bchsia.telus.net] has joined #bzr | ||
| jelmer | NfNitLoop: is there a trailing slash after the repository location? | 03:03 |
| jelmer | NfNitLoop: what location do you specify when you try to push? | 03:04 |
| NfNitLoop | no trailing slash. I'm pushing to 'svn+https://<repo>/trunk' | 03:04 |
| NfNitLoop | 'bzr info' show that "push branch" and "parent branch" are identical. | 03:05 |
| jelmer | NfNitLoop: and the ls -r0 is the last line before the crash? | 03:07 |
| NfNitLoop | yep. | 03:08 |
| jelmer | NfNitLoop: please update the plugin and try again, I think I've fixed it | 03:13 |
| NfNitLoop | jelmer: 'k. :) | 03:13 |
| NfNitLoop | I hope it's OK to just leave a bzr repo in ~/.bazaar/plugins/svn. It makes it easy to stay up to date. :) | 03:14 |
| NfNitLoop | jelmer: Success! | 03:14 |
| NfNitLoop | Thanks for all your help. :) | 03:14 |
| NfNitLoop | Now, all of that was on my test repo. Any suggestions on checking out my large one that keeps crashing? :p | 03:15 |
| jelmer | NfNitLoop: is that still crashing? | 03:15 |
| NfNitLoop | I haven't tried it with these latest changes. | 03:15 |
| NfNitLoop | think I'd have better luck? | 03:15 |
| === NfNitLoop goes off to start it. | ||
| jelmer | yes, I think it should work now | 03:16 |
| jelmer | the http support in bzr-svn has been a bit unstable because there's no testsuite for it | 03:16 |
| NfNitLoop | Hmm, let me shut down X first to give it a bit more room to play in. :) | 03:16 |
| jelmer | in *theory* it should behave exactly the same way that the other transports do, but there are subtle differences | 03:16 |
| === fullermd can't believe somebody just said "no testsuite" on #bzr. | ||
| jelmer | in theory, the abstraction in python-subversion should take care of it | 03:18 |
| jelmer | fullermd: I don't really feel like bootstrapping apache, webdav and subversion as part of the bzr-svn testsuite.. :-) | 03:19 |
| NfNitLoop | I also just learned that you can use checkout to create a wc in the repo directory. (That just seemed... wrong, for some reason.) | 03:19 |
| fullermd | Pfft. As if that's an excuse. You gotta be committed, man! | 03:21 |
| fullermd | Think of it this way; if you bootstrapped svn in the test suite, we wouldn't need to worry about trying to get a patched version installed on our systems; just run the test suite, and it installs it! | 03:22 |
| NfNitLoop | What was the issue with needing a patched version of svn, anyway? | 03:23 |
| jelmer | the subverison python bindings are horribly broken in earlier versions of svn (< 1.5) | 03:24 |
| fullermd | Does the trunk now have all of the fixes integrated? | 03:27 |
| jelmer | fullermd: yep, that's where I originally fixed python-subversion | 03:29 |
| === pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr | ||
| NfNitLoop | Hmm... about 20% done and my computer's still responsive. :) | 03:34 |
| NfNitLoop | I should probably invest in more RAM for that machine anyway. It's so old now I but whatever ram it uses is cheap. :p | 03:35 |
| fullermd | The rate fabs are turning over, it's probably more expensive than the fastest new stuff :p | 03:36 |
| NfNitLoop | doh! | 03:36 |
| fullermd | I've looked a couple of times at faster CPU's for this machine, but it would be cheaper to completely replace the motherboard, even including RAM. | 03:36 |
| NfNitLoop | hehe, wow. | 03:37 |
| NfNitLoop | aha! I can ctrl-c, then go do a "bzr pull" to continue, before the leaky python-svn library eats up my ram. :) | 03:38 |
| jelmer | yup | 03:41 |
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| NfNitLoop | Doh. bzr: ERROR: exceptions.AssertionError: | 03:53 |
| jelmer | where? | 03:53 |
| NfNitLoop | .bazaar/plugins/svn/fetch.py", line 306, in close_file assert checksum is None or checksum == actual_checksum | 03:53 |
| NfNitLoop | trying to resume. | 03:54 |
| NfNitLoop | Hrmm, well, the resume hasn't failed yet. Bad checksum it seems? *shrug* | 03:59 |
| jelmer | NfNitLoop: hmm, strange | 04:15 |
| NfNitLoop | jelmer: seems to be working OK now. :) | 04:18 |
| NfNitLoop | jelmer: if a branch is created in the subversion repository at a later point in time... | 04:54 |
| NfNitLoop | how would I go about checking out that branch in my bzr repo? | 04:55 |
| NfNitLoop | just bzr branch svn+https://<repo>/branches/the-branch in the shared repo directory? | 04:55 |
| NfNitLoop | what I'm wondering is if it would be smart enough not to re-fetch all of the history in that case. :) | 04:56 |
| jelmer | NfNitLoop: yep, just bzr branch will work | 05:03 |
| jelmer | it won't refetch history it already has | 05:03 |
| keir | anyone here familiar with the transport code? | 05:24 |
| keir | i'm designing a stand-alone compact dictionary format | 05:24 |
| keir | but i'm going to reuse it within the graph itself | 05:25 |
| keir | so this serialization will be embedded | 05:25 |
| keir | can i make a 'view' on a file with a transport? | 05:25 |
| === BasicOSX [n=Basic@fortress.tanners.org] has joined #bzr | ||
| === ionstorm [n=ion@71-36-164-32.phnx.qwest.net] has joined #bzr | ||
| === abentley [n=abentley@bas8-toronto63-1088754407.dsl.bell.ca] has joined #bzr | ||
| NamNguyen | hi abentley, is there a plan to let BundleBuggy support more than one branch locations? | 07:34 |
| NamNguyen | i could imagine that detecting for which branch a merge request is will be a problem | 07:36 |
| Odd_Bloke | NamNguyen: Do you mean have a single BundleBuggy instance pick up merge requests for, for example, bzr and bzrtools from the same mailing list? | 07:39 |
| NamNguyen | that is correct | 07:40 |
| NamNguyen | Odd_Bloke, and if you have looked at BB's code | 07:40 |
| NamNguyen | there is a tool to automatically mark merge requests as "merged" | 07:40 |
| NamNguyen | it would need to support multiple branches too | 07:41 |
| abentley | NamNguyen: No immediate plans. Merge directives do include a target branch, so the only problem is that people don't send merge directives with useful target branches. | 07:42 |
| abentley | But for patches or plain bundles, there's no way to know. | 07:43 |
| NamNguyen | the recommended practice is to make a local branch from bzr.dev, then branch from that local branch to make changes | 07:44 |
| NamNguyen | in that case, isn't the target branch pointing to the local bzr.dev? | 07:44 |
| abentley | If there is a public location for the target branch, the public branch is used in the merge directive. | 07:46 |
| abentley | Have a look at any of my merge directives, and you'll see http://bazaar-vcs.org/bzr/bzr.dev as the target location, even though I used a local copy of bzr.dev | 07:48 |
| === luks [i=lukas@unaffiliated/luks] has joined #bzr | ||
| Odd_Bloke | Can bzr nickname remote branches like git does with 'git remote add <name> <location>'? For reference, you can then do 'git fetch <name>' which is equivalent to 'git fetch <location>' (or so is my understanding). | 09:15 |
| === ionstorm [n=ion@71-36-164-32.phnx.qwest.net] has joined #bzr | ||
| === ionstorm [n=ion@71-36-164-32.phnx.qwest.net] has joined #bzr | ||
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| === mwh [n=mwh@gustomal-adsl.demon.co.uk] has joined #bzr | ||
| === pygi [n=mario@83-131-27-15.adsl.net.t-com.hr] has joined #bzr | ||
| === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr | ||
| === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr | ||
| === gakster [i=96656340@gateway/web/cgi-irc/ircatwork.com/x-11ba859992bd94a0] has joined #bzr | ||
| === gakster [i=96656340@gateway/web/cgi-irc/ircatwork.com/x-61e1b70bc13d598b] has joined #bzr | ||
| gakster | hi all, i have tried to learn the difference between DARCS distributed method and Subversions centralised.... but is there anyone who might like to try to explain it to me again. I am still confused | 12:05 |
| gakster | all I understand is that with the distributed method, every copy of the files is a repository of an equal level, and patches are shared amongst users | 12:06 |
| gakster | with subversions centralised method.... there is one MAIN repository, and everyone works throug that | 12:06 |
| gakster | is there more to it than that? | 12:06 |
| Peng | gakster: With the centralized model, there's one repository, and only certain authorized people can commit to it. In the distributed model, everybody has his own repository and can commit to it and put it on a server for other people. | 12:17 |
| Peng | gakster: One benefit of the distributed model is that since the VCS has to merge changes between different peoples' branches frequently, it has to be damn good at it. | 12:18 |
| Peng | gakster: That's purely the technically differences. Socially, the distributed model is way better (IMO and with one or two exceptions, of course). | 12:21 |
| pygi | distributed model also allows you to merge patches from people, and credit it to them. Where in svn if someone who doesn't have commit access and sends you a patch, you commit it, and therefore it looks like you did it | 12:27 |
| pygi | s/merge/cherrypick | 12:27 |
| gakster | in what social situations is centralised better than distributed? | 12:31 |
| gakster | what if i want to use version control to just keep track of changes to my website..... I dont need multiple copies of my website... i just need one repository | 12:32 |
| === mwh [n=mwh@81.187.73.203] has joined #bzr | ||
| === duckx [n=Duck@tox.dyndns.org] has joined #bzr | ||
| pygi | gakster, distributed is much easier as in most cases you don't need a special server | 12:37 |
| pygi | bzr, git, mercurial ... distributed, without server | 12:37 |
| pygi | svn, cvs, perforce ... centralized, need server | 12:38 |
| gakster | I like the idea of not needing to install a server..... this is a positive of distrubted | 12:42 |
| gakster | does anyone know why the http://darcs.net/ webpage has been crashed for a few days now? | 12:43 |
| pygi | for bzr however there is smart server if you wish, that allows improvements in performance | 12:43 |
| pygi | not really, this is bzr channel =) | 12:43 |
| gakster | sorry, dont know who else to ask :-) | 12:44 |
| gakster | i congratulate bazaar for having a webpage that doent look ugly.... it is important for people like me who are more graphical windows users... well done! | 12:49 |
| gakster | also great that you have some NON technical documentation | 12:49 |
| gakster | does anyone have a suggestion as to the best windows GUI. I am looking for simplicity and ease of use. And nice pretty colours for diff reports | 12:51 |
| === dato [n=adeodato@tarrio.org] has joined #bzr | ||
| pygi | gakster, Olive? :) | 12:56 |
| pygi | well, there's this bzr-gtk that should work, and it includes Olive | 12:56 |
| pygi | and all the other cool things | 12:57 |
| === sadleder [n=sadleder@p50810F06.dip0.t-ipconnect.de] has joined #bzr | ||
| === sadleder [n=sadleder@p50810F06.dip0.t-ipconnect.de] has left #bzr [] | ||
| gakster | what about http://bazaar-vcs.org/TortoiseBzr how is this different from bzr-gtk | 01:07 |
| pygi | it's something like tortoisesvn | 01:08 |
| pygi | I'm not aware of it's staus | 01:09 |
| pygi | status | 01:09 |
| gakster | I have downloaded and installed the standalone windows install of bazaar..... for me to be able to use olive and other br-gtk.... it says i need to have a python based install, and need a bunch of other dependencies? is this right? | 01:22 |
| gakster | sounds too hard for me | 01:23 |
| === asabil [n=asabil@ti0035a340-0802.bb.online.no] has joined #bzr | ||
| === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr | ||
| === nir [n=nir@moinmoin/fan/nir] has joined #bzr | ||
| === grimboy_uk [n=grimboy@85.211.237.72] has joined #bzr | ||
| === grimeboy [n=grimboy@85.211.239.211] has joined #bzr | ||
| === MaSch [n=masch@p5091900E.dip0.t-ipconnect.de] has joined #bzr | ||
| MaSch | Hi | 02:15 |
| MaSch | maybe its a stuid question, but i never worked with svn-systems befor so, how i use this? So if i have a server, where all the files are stored and where bzr runs, how i edit them and upload them back to the server? | 02:17 |
| MaSch | and sorry for my bad english | 02:17 |
| MaSch | so with bzr branch <url> i get the files to my local machine, but how i upload them to the server? | 02:21 |
| jelmer | bzr commit | 02:23 |
| jelmer | followed by 'bzr push' | 02:23 |
| jelmer | 'bzr commit' records the changes | 02:23 |
| jelmer | 'bzr push' uploads the changes | 02:23 |
| MaSch | okay thanks | 02:23 |
| MaSch | its that easy.. nice.. | 02:23 |
| === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr | ||
| === phanatic [n=phanatic@dsl54028306.pool.t-online.hu] has joined #bzr | ||
| dirker | Hello :) How good is bazaar suited to host a project with source aswell as binary files? I'm minly thinking of merges and compression of the history. | 02:52 |
| === g0ph3r [n=g0ph3r@p57A097F4.dip0.t-ipconnect.de] has joined #bzr | ||
| === mwh [n=mwh@81.187.73.203] has joined #bzr | ||
| === mdke [i=mdke@ubuntu/member/mdke] has joined #bzr | ||
| mdke | I'd like to try and create a patch which spans several revisions I've made to a branch, but not others; is that possible? | 03:10 |
| pygi | mdke, cherrypicking? | 03:26 |
| === mwh [n=mwh@81.187.73.203] has joined #bzr | ||
| === Gwaihir [n=Gwaihir@ubuntu/member/gwaihir] has joined #bzr | ||
| pygi | mdke, if that's what you think, then yes, you can do it | 03:31 |
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| === dpm [n=dpm@p54A130EE.dip0.t-ipconnect.de] has joined #bzr | ||
| === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr | ||
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr | ||
| === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr | ||
| mdke | pygi: how? | 04:16 |
| === pygi thinks | ||
| pygi | cherrypicking needs to be improved in bzr, but : | 04:18 |
| pygi | bzr merge -r 81..82 ../bzr.dev | 04:18 |
| pygi | perhaps this should do the trick? | 04:18 |
| pygi | just an example | 04:19 |
| mdke | pygi: I need to create a patch though... | 04:19 |
| pygi | mdke, well, do cherrypicking, and the do a diff against the original tree? | 04:20 |
| mdke | ah, interesting. | 04:21 |
| mdke | thanks, I'll look into that | 04:21 |
| pygi | mdke, yw | 04:21 |
| phanatic | mdke: maybe bzr diff -r X..Y ? | 04:25 |
| === mwh [n=mwh@81.187.73.203] has joined #bzr | ||
| Odd_Bloke | phanatic: That'll diff between the two revisions. | 04:31 |
| mdke | phanatic: I'm going to try pygi's because it will help me get a patch that I can apply cleanly against the original branch (I've made quite a lot of other changes to the branch which I don't want to include in the patch) | 04:33 |
| phanatic | mdke: sorry, i misunderstood you a bit :( | 04:34 |
| mdke | np | 04:34 |
| === tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr | ||
| === fog [n=fog@debian/developer/fog] has left #bzr [] | ||
| === pmezard [n=pmezard@nor75-4-81-56-59-92.fbx.proxad.net] has joined #bzr | ||
| === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr | ||
| === rents [n=db@84-50-162-133-dsl.rgu.estpak.ee] has joined #bzr | ||
| rents | hi, do i have to recompile everything after doing "bzr up"? | 05:25 |
| rents | always | 05:25 |
| pygi | o.O | 05:25 |
| pygi | what do you want to recompile? | 05:25 |
| rents | if i am updating something | 05:25 |
| Odd_Bloke | rents: You always have to recompile a project if the source code changes. | 05:26 |
| Odd_Bloke | rents: Assuming it's a project which requires compiling. | 05:26 |
| Odd_Bloke | Whether this is through you editing a file or 'bzr update' modifying a file is immaterial. | 05:26 |
| rents | then i should now figure out if this project really needs recompiling | 05:27 |
| rents | exaile in this case | 05:27 |
| pygi | rents, it doesn't | 05:27 |
| pygi | exaile is written in python | 05:28 |
| rents | and won't need it? | 05:28 |
| rents | <- total newb | 05:28 |
| Odd_Bloke | rents: Python doesn't require compilation, it's an interpreted language. | 05:28 |
| pygi | why dont you ask adam? | 05:28 |
| rents | ok, that's all i wanted to know | 05:29 |
| rents | thank you guys | 05:29 |
| rents | bye for now | 05:29 |
| === GaryvdM [n=chatzill@mtngprs4.mtn.co.za] has joined #bzr | ||
| === Zindar [n=erik@h188n1fls12o803.telia.com] has joined #bzr | ||
| === ionstorm [n=ion@71-36-164-32.phnx.qwest.net] has joined #bzr | ||
| === pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr | ||
| === arjenAU_ [n=arjen@ppp215-29.static.internode.on.net] has joined #bzr | ||
| ubotu | New bug: #138437 in bzr "Cannot revert single files via olive" [Undecided,New] https://launchpad.net/bugs/138437 | 06:25 |
| mdke | pygi: I'm trying your method, the first revision worked well, but now I'm trying to apply another revision and it won't let me without committing the changes | 06:30 |
| mdke | pygi: is there any way around that? | 06:30 |
| dato | no, but you can commit in a throwaway patch, which you can remove after generating the diff. | 06:32 |
| luks | you can use --force | 06:32 |
| dato | oh. | 06:32 |
| mdke | I'll try; I can't commit anyway because I did a checkout | 06:32 |
| luks | but it's probably better to have it as multiple commits and then generate diff over the range of new commits | 06:32 |
| luks | oh | 06:32 |
| mdke | wow, --force has done the trick | 06:33 |
| pygi | ;) | 06:33 |
| mdke | and the revisions have applied cleanly \o/ | 06:33 |
| pygi | mdke, see? :) | 06:34 |
| mdke | that's pretty awesome | 06:34 |
| mdke | shame the code doesn't work | 06:35 |
| pygi | mdke, well, I'm off to dinner, but if you need anything poke | 06:37 |
| mdke | pygi: thanks, I think I've got there, just have to fix the code | 06:37 |
| pygi | mdke, kk, congrats ;) | 06:38 |
| ubotu | New bug: #138439 in bzr "Cannot select multiple files and execute a command in olive" [Undecided,New] https://launchpad.net/bugs/138439 | 06:40 |
| phanatic | heh | 06:41 |
| phanatic | olive bugs filed under bzr, nice | 06:41 |
| === mdke [i=mdke@ubuntu/member/mdke] has left #bzr ["goodbye!"] | ||
| ubotu | New bug: #138446 in bzr "Cannot import from svn" [Undecided,New] https://launchpad.net/bugs/138446 | 07:11 |
| luks | ... and bzr-svn bugs files under bzr :) | 07:18 |
| luks | *filed | 07:18 |
| === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr | ||
| pygi | phanatic, fix it =) | 07:24 |
| MaSch | whats olive? | 07:26 |
| Odd_Bloke | MaSch: A GTK frontend for bzr, I think. | 07:26 |
| MaSch | okay thanks | 07:26 |
| pygi | Odd_Bloke, you're right | 07:26 |
| === asak [n=alexis@201-1-47-31.dsl.telesp.net.br] has joined #bzr | ||
| === fog [n=fog@debian/developer/fog] has joined #bzr | ||
| === pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr | ||
| === ACSpike[Home] [n=ACSpike@66.60.213.51] has joined #bzr | ||
| ACSpike[Home] | hello | 07:41 |
| pygi | hi ho | 07:41 |
| Odd_Bloke | If I'm branching into a shared repository (from a remote branch) is there any way to resume after interruption? | 08:14 |
| dato | the fetched revisions will be present in the repository, so remove the branch and rebranch | 08:15 |
| === Mez [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| === matkor [n=matkor@ip83-230-19-175.e-zabrze.pl] has joined #bzr | ||
| === grimboy_uk [n=grimboy@85.211.238.12] has joined #bzr | ||
| lifeless | moin | 09:29 |
| === tca [n=tom@ti541110a080-5238.bb.online.no] has joined #bzr | ||
| lifeless | jelmer: ping | 09:32 |
| lifeless | dato: ping | 09:32 |
| dato | lifeless: pong | 09:32 |
| lifeless | hi | 09:32 |
| lifeless | bzr packages for gutsy are going to be updated real soon now | 09:32 |
| jelmer | lifeless: pong | 09:33 |
| lifeless | where you planning on a bzr-svn 0.4.2 upload to sid today ? | 09:33 |
| === GaryvdM_ [n=chatzill@mtngprs4.mtn.co.za] has joined #bzr | ||
| jelmer | lifeless: the debian branch is up to date | 09:34 |
| lifeless | jelmer: package not branch. | 09:34 |
| lifeless | I use the terms advisedly because of the various processess involved | 09:34 |
| === GaryvdM_ is now known as GaryvdM | ||
| jelmer | lifeless: ah, right | 09:34 |
| lifeless | now, I can upload bzr-svn to debian if you are happy with the packaging. | 09:35 |
| lifeless | thats kinda trivial :) | 09:35 |
| jelmer | lifeless: yup, please do | 09:35 |
| dato | lifeless: ok. you needed something or were just telling? | 09:37 |
| lifeless | dato: if you were doing a bzr-svn upload I would not do one | 09:38 |
| lifeless | dato: I was coordinating | 09:38 |
| dato | ah, good. just fyi it'll prevent bzr 0.90 from getting to testing, but I don't think that's happening anytime soon either because of a failed mipsel build. | 09:39 |
| lifeless | dato: I'm not worried about testing right now :) - why will it prevent it though ? | 09:40 |
| dato | prevent in less that 10 days, I meant | 09:40 |
| lifeless | jelmer: http://bzr.debian.org/pkg-bazaar/bzr-gtk/unstable ? seems out of date | 09:40 |
| lifeless | oh crap | 09:40 |
| lifeless | bzr-svn doh | 09:40 |
| === GaryvdM_ [n=chatzill@mtngprs5.mtn.co.za] has joined #bzr | ||
| === GaryvdM_ is now known as GaryvdM | ||
| === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr | ||
| keir | lifeless, ping! | 09:48 |
| lifeless | hi | 09:49 |
| keir | i wrote the dictionary builder | 09:50 |
| keir | and am 1/3 way through the reader | 09:50 |
| keir | it's compressed btree | 09:50 |
| keir | lifeless, do you have couple mins to chat about it? | 09:52 |
| lifeless | sure | 09:52 |
| keir | ok | 09:53 |
| keir | i branched from bzr.dev instead of packs.knits | 09:53 |
| keir | but the code is contained in two files, so it should be easy to switch | 09:53 |
| GaryvdM | jelmer: I've been hacking away at viz. I've finish a proof of concept that loads the revisions incrementaly. | 09:54 |
| GaryvdM | It's published here: http://bazaar.launchpad.net/~garyvdm/bzr-gtk/vizchanges | 09:54 |
| keir | lifeless, so what i have is just like i described in the 2nd email regarding a separate dictionary | 09:55 |
| keir | except that if the 'index' block is larger than the block size, it recurses | 09:55 |
| GaryvdM | There are still some bugs in the code to work out where the lines need to be - Some of the lines are drawn on top of each other. | 09:55 |
| lifeless | I think that makes it a b+ tree :) | 09:56 |
| keir | lifeless, oh. heh | 09:56 |
| keir | hmm, i'm lacking a webserver | 09:57 |
| lifeless | you probably want to merge it with packs and do some adhoc testing yourself | 09:57 |
| lifeless | (keeping your branch separate and unmerged is fine; I just mean have a copy that is integrated) | 09:58 |
| siretart | hi lifeless | 09:58 |
| siretart | lifeless: do you plan to update bzr in gutsy? | 09:58 |
| keir | lifeless, ok | 09:58 |
| lifeless | siretart: see above | 09:58 |
| siretart | oh, sry | 09:59 |
| lifeless | siretart: the answer is yes, but someone needs to do the uvfe dance for about 6 packages | 09:59 |
| lifeless | bzr bzr-gtk bzrtools bzr-svn bzr-rebase bzr-builddeb all need updates IIRC | 09:59 |
| siretart | lifeless: in past releases, there were no uvfe reports for bzr packages | 09:59 |
| lifeless | in the past we were not updatng 3 days before beta | 10:00 |
| siretart | ah, ok | 10:00 |
| keir | lifeless, pushing my branch now. it's still based off bzr.dev until i have at least the dictionary functionally complete | 10:02 |
| keir | we gotta fix that progress bar | 10:03 |
| keir | it's so totally useless | 10:03 |
| fullermd | If we just got all operations completing in under 5 seconds, we wouldn't need a progress bar. | 10:03 |
| keir | working on it! | 10:03 |
| lifeless | fullermd: the internets are slow | 10:04 |
| lifeless | fullermd: pushing 2G of data >>>> 5 seconds | 10:04 |
| fullermd | Well, can't we just rewrite the slow parts in C? | 10:04 |
| keir | fullermd, the problem is the data formats (i think?) | 10:04 |
| keir | push is going on 4 minutes now | 10:04 |
| lifeless | keir: fullermd is our resident troll-resistance-tester | 10:04 |
| lifeless | keir: initial push is slow for knits because of round trip latency on each knit | 10:05 |
| lifeless | keir: if you are using sftp, its either 3 or 4 round trips per file, and 2 files per knit. | 10:05 |
| === Mez [n=Mez@ubuntu/member/mez] has joined #bzr | ||
| keir | aaah! | 10:05 |
| lifeless | packs are only 20% slower than rsync | 10:05 |
| keir | sweet | 10:05 |
| keir | does sftp do its own compression? | 10:05 |
| keir | regardless of whether we speed things up, i still want nice progress bars | 10:07 |
| jelmer | GaryvdM: cool | 10:08 |
| jelmer | GaryvdM: I'll try it out this week! | 10:08 |
| keir | aaaag only 2 modified files and push is still going | 10:09 |
| keir | 8 minutes now | 10:09 |
| keir | lifeless, i'm thinking of building a 1st version that does away with the separate storage for the graph | 10:10 |
| keir | and just packs the keys (as dumb strings even!) into the dictionary | 10:10 |
| keir | since it should be very easy to code, i figure it's a worthwhile experiment | 10:10 |
| keir | is there a benchmark suite waiting for me to try out? | 10:10 |
| lifeless | that sounds very close to the toy index, just with a B+ tree rather than bisectable array. :) | 10:11 |
| lifeless | some of the benchmarks may help, but really for this size data - no. | 10:11 |
| keir | lifeless, sftp://mierle@bazaar.launchpad.net/~mierle/bzr/compactgraph; not done the push yet. i'll be back in 1/2 hr | 10:11 |
| lifeless | to test it out I'd suggest converting bzrlib to packs using it | 10:11 |
| lifeless | and then trying things like : | 10:12 |
| lifeless | bzr cat | 10:12 |
| lifeless | bzr log FILENAME | 10:12 |
| lifeless | bzr merge | 10:12 |
| keir | ok | 10:12 |
| keir | i tried the dogfooding instructions, and it didn't work when i tried to branch the pack version | 10:13 |
| keir | which is why i branched bzr.dev | 10:13 |
| keir | brb in 15 | 10:14 |
| lifeless | we have a corrupt data item, which is noted in the followup mails about dogfooding | 10:14 |
| lifeless | jelmer: where is the bzr-svn tarball ? | 10:30 |
| === pygi [n=mario@83-131-30-103.adsl.net.t-com.hr] has joined #bzr | ||
| jelmer | http://samba.org/~jelmer/bzr/bzr-svn-0.4.2.tar.gz | 10:32 |
| lifeless | also, consider signing the targz please | 10:32 |
| lifeless | I can quite easily construct a tar.gz which when piped through gunzip -c | gpg verifies | 10:34 |
| lifeless | but when tar xzf'd does something different | 10:34 |
| lifeless | jelmer: ^ | 10:35 |
| jelmer | I'd rather be consistent with the way I have to do other releases, but I'll consider it for 0.4.3 | 10:35 |
| === pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr | ||
| lifeless | jelmer: what other releases require this? | 10:35 |
| lifeless | oh, your debian branch has the packaging mixed with the code? | 10:36 |
| jelmer | lifeless: it's the convention for samba projects | 10:37 |
| lifeless | hmm | 10:37 |
| lifeless | well, try creating a tar that overrides /boot/grub/menu.lst | 10:38 |
| jelmer | lifeless: yep, makes it easier to diverge a bit from the main branch without having to use quilt or anything | 10:38 |
| lifeless | and then cat that tar before your release tar as two gzip streams | 10:38 |
| === pygi [n=mario@83-131-30-103.adsl.net.t-com.hr] has left #bzr ["Leaving"] | ||
| jelmer | well, I do suggest running gpg on the actual unpacked tarball rather than piping through gunzip but I see your point. | 10:42 |
| lifeless | I encourage you to change the samba release process | 10:42 |
| lifeless | create two tarballs | 10:42 |
| lifeless | sha1sum *tar.* > listing | 10:42 |
| lifeless | gpg --clearsign listing | 10:43 |
| lifeless | or something like that | 10:43 |
| lifeless | should be no harder | 10:43 |
| lifeless | same number of gpg sigs | 10:43 |
| === pete__c [n=pete@015-806-741.area5.spcsdns.net] has joined #bzr | ||
| lifeless | easier for users to validate the content (don't need to unbzip2 or whatever) | 10:43 |
| jelmer | well, it does add an extra step running sha1sum for the user and comparing that to the sha1sum in the listing | 10:47 |
| jelmer | The actual number of users downloading the signature is a bit disappointing | 10:48 |
| === grimeboy [n=grimboy@85-211-247-60.dsl.pipex.com] has joined #bzr | ||
| fullermd | Just slip a trojan into a release. That'll encourage them. | 10:49 |
| keir | lifeless, did manage to get that branch? | 10:50 |
| === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr | ||
| NfNitLoop | *sigh* getting PyCrypto onto Windows w/ python 2.5 is turning out to be non-trivial. | 10:51 |
| lifeless | keir: haven't tried yet | 10:52 |
| lifeless | keir: I am focused on commit performance right now, I'll happily look at your branch when you're a bit further along, or if you would like specific feedback | 10:52 |
| lifeless | jelmer: +1 step -1 step +security :) | 10:53 |
| keir | lifeless, ok, cool. just looking for overall thoughts on my design before i get any further | 10:53 |
| keir | i'd rather fix design issues early | 10:54 |
| keir | see compact_graph.py | 10:54 |
| lifeless | keir: I think you have those via the list :) | 10:54 |
| lifeless | but sure, I'll do a pull later today | 10:54 |
| keir | maybe it is better to wait until i have it running | 10:55 |
| keir | ok, nevermind then, i'll make it go then mail it to the list. | 10:55 |
| lifeless | hmm, I will pull and peek :) | 11:02 |
| lifeless | but mailing the list is always good :) | 11:03 |
| === tca [n=tom@ti541110a080-5238.bb.online.no] has left #bzr [] | ||
| === ACSpike[Home] [n=ACSpike@66.60.213.51] has left #bzr [] | ||
| lifeless | damn missed abentley | 11:13 |
| keir | lifeless, so for initial commit, are you speeding up the pack-based commit? | 11:17 |
| lifeless | yes | 11:17 |
| lifeless | I can commit a 550MB tree with 55K files in 1m48 user time | 11:17 |
| lifeless | bzr.dev is about 10 minutes IIRC | 11:18 |
| keir | sweet! | 11:18 |
| keir | how long is git and hg? | 11:18 |
| lifeless | hg is 1m user time | 11:18 |
| lifeless | 1m30 wall clock, my test code is 2m2 wall clock | 11:19 |
| lifeless | git I'm not sure right now | 11:19 |
| keir | that's pretty decent | 11:19 |
| keir | do you think we can beat hg? | 11:19 |
| lifeless | dunno | 11:19 |
| lifeless | I'm sure we can make the speed difference unimportant | 11:19 |
| lifeless | we don't claim to be the fastest system, only the nicest. | 11:20 |
| lifeless | 'only' :) | 11:21 |
| keir | :) | 11:24 |
| keir | i imagine we can get most ops to within 20% of hg and git | 11:24 |
| lifeless | I'm aiming to be no slower than twice targz | 11:24 |
| lifeless | for initial commit | 11:24 |
| lifeless | which is incidentally faster than hg IIRC | 11:24 |
| keir | cool | 11:25 |
| keir | what approach are you taking to making the initial case so fast? | 11:25 |
| keir | are you special casing it? | 11:25 |
| lifeless | profile | 11:25 |
| lifeless | analyse | 11:25 |
| lifeless | change | 11:25 |
| lifeless | test | 11:25 |
| lifeless | repeat | 11:25 |
| lifeless | not as such no | 11:26 |
| keir | that's good | 11:26 |
| keir | is the 1:48 figure with some pyrex? | 11:27 |
| lifeless | nope | 11:27 |
| keir | wow, nice | 11:27 |
| lifeless | no pyrex, commit -q | 11:27 |
| keir | would there be any benefit to combining add * and commit? | 11:27 |
| lifeless | yes | 11:27 |
| lifeless | though add is very fast | 11:27 |
| keir | i still want a single command 'GO' which adds all non-hidden files and commits | 11:27 |
| keir | init + add + commit | 11:28 |
| lifeless | heh | 11:28 |
| lifeless | you can do that trivially in a plugin | 11:28 |
| keir | i know :) and i will, just not today | 11:28 |
| keir | i'd like it to be upstream, rather than a plugin | 11:28 |
| keir | so you can show peoplle how easy bzr is | 11:28 |
| lifeless | well | 11:28 |
| keir | right now it's as easy as 1) init 2) add 3) commit | 11:28 |
| lifeless | thats an extremely special cased situation | 11:29 |
| keir | but with go, it's as easy as 1) go :) | 11:29 |
| lifeless | commit -A is something I think is agreed on | 11:29 |
| lifeless | which is add/remove automatically during commit | 11:29 |
| keir | perhaps init -A? | 11:29 |
| lifeless | it would have to live on init I think if we were to do such a special case | 11:30 |
| lifeless | btw, I dunno if you know but you can import tarballs directly | 11:30 |
| keir | woah, i didn't know that | 11:30 |
| lifeless | its in bzrtools | 11:30 |
| lifeless | but I have been thinking its such a nice thing we could move it in | 11:31 |
| keir | +1 on that | 11:31 |
| keir | when i look at my use of bzr, it's always 'bzr init; bzr add .; bzr ci -m"Initial commit"' | 11:31 |
| keir | so i don't see the point in not having that as a single command | 11:32 |
| lifeless | you must start lots of projects :) | 11:32 |
| keir | i version little stuff, because it's so easy with bzr | 11:32 |
| keir | with svn it's annoying | 11:32 |
| keir | ok, i'm out on the bus | 11:33 |
| dato | I agree to that | 11:33 |
| keir | we'll see if i can get dict reading working by the time i get back from TO | 11:33 |
| dato | creating lots of independent branches for not-so-big stuff | 11:33 |
| keir | lates | 11:34 |
| === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr | ||
| === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!