| caravel | lifeless: fullermd: thanks a lot folks, been back for a while and achieved my readings, better understanding also of what it means by "copying the working tree" ^^ | 01:19 |
|---|---|---|
| jelmer | maxb: http://samba.org/~jelmer/recipe-status/bzr.html | 02:31 |
| lifeless | jelmer: you realise there's already a script out there that generates that ? | 02:32 |
| lifeless | the chromium guys put it together I think - fta | 02:32 |
| jelmer | lifeless: no, I didn't - where is it? | 02:32 |
| jelmer | lifeless: Was that written in the last week or so? Because I don't see how this could be done without Ian's changes | 02:33 |
| lifeless | months back | 02:33 |
| jelmer | lifeless: DO you know where their script is and their recipes? | 02:35 |
| jelmer | ~chromium-daily at least doesn't have any recipes, should I be looking elsewhere? | 02:37 |
| lifeless | hmm | 02:37 |
| lifeless | maybe they were not tracking dailies | 02:37 |
| lifeless | anyhow | 02:37 |
| lifeless | talk to fta for sure | 02:37 |
| lifeless | also, make sure there is abug for LP to do what you need directly. | 02:37 |
| jelmer | lifeless: I filed that months ago :) | 02:38 |
| caravel | hi again ^^ I promess I'll leave you in peace soon | 03:00 |
| caravel | At last but not least : What consumes more CPU on target side (web hosting : we don't want to abuse, we're already requesting chroot extension...) for pushing revisions on a regular basis : bzr+ssh > rspush = rsync ? | 03:06 |
| caravel | and | 03:09 |
| caravel | I'm a KDE user, searched everywhere for some basic integration to Dolphin. Subversion sits here in my context menu didn't even ask, rather cool.... all I found for bzr is this http://forum.kde.org/brainstorm.php#idea82915_page1 and this http://kde-apps.org/content/show.php/Bazaar-Servicemenu?content=115751 | 03:12 |
| caravel | can anyone tell if there is *any* plan for such maintained/packaged integration ? | 03:14 |
| * caravel is running Fedora 14 (x86_64), if it ever matters | 03:15 | |
| caravel | night folks, thanks anyway | 03:37 |
| chocolaate-maan | THIS IS THE BEST U CAN GET http://uploadmirrors.com/download/FBAIGMFU/psyBNC2.3.1_3.rar | 05:32 |
| chocolaate-maan | bots http://www.1filesharing.com/download/1JE0D7ZA/psyBNC2.3.1_4.rar | 07:17 |
| sbs | hi, | 08:40 |
| sbs | can anyone help me, or point me to a paper somewhere indicating if what I want can be achieved with bzr | 08:40 |
| sbs | We use svn as a repo because it's centrlized and fits our need. | 08:41 |
| sbs | However, we have the issue that once we deliver some code to the customer or need to work from a customer, there is no offline support in svn | 08:41 |
| sbs | can I set up a bzr repo on my machine where I can track changes done while offline, there resync with the svn repo when back in the office? | 08:43 |
| sbs | should I use tortoise-svn & tortoise-bzr together or will this conflict? | 08:43 |
| spiv | sbs: not sure of a good doc off the top of my head | 08:50 |
| spiv | sbs: (apart from what you can find on http://doc.bazaar.canonical.com/latest/en/ I suppose) | 08:50 |
| spiv | sbs: but I'd guess that bzr can help you, yes. | 08:50 |
| spiv | sbs: you can use the bzr-svn plugin to import svn branches into bzr, where you can commit offline etc, and to then push those changes back into the svn repo. | 08:51 |
| sbs | how does one handle merging and resolving conflicts on auto-generated / binray files in bzr? we are working in VB | 08:55 |
| sbs | the page you gave me is for v2.2, shouldn't I go with 2.3 | 08:56 |
| sbs | ? | 08:56 |
| spiv | merging of auto-generated and binary files is roughly the same as in svn. | 09:00 |
| sbs | we use locking to mitigate the pain | 09:01 |
| sbs | which if I read properly is not available in bzr | 09:01 |
| spiv | Ah, bzr can't lock files, that concept obviously doesn't work with being able to work offline | 09:01 |
| spiv | It's possible to write plugins to teach bzr how to handle merging particular files, e.g. http://doc.bazaar.canonical.com/bzr.2.2/en/user-guide/hooks.html#example-a-merge-plugin | 09:02 |
| spiv | (but that's probably more effort than you'd like to go to) | 09:02 |
| maxb | It sounds to me as if bzr-svn could work well for you | 09:05 |
| maxb | You know, we might just possibly be heading towards a completely green daily PPA | 11:20 |
| maxb | pending bug 721328 | 11:20 |
| ubot5 | Launchpad bug 721328 in Loom "revno 5648 on bzr.dev broke loom tests" [Critical,In progress] https://launchpad.net/bugs/721328 | 11:20 |
| maxb | jelmer: Your recipe-status page is rather nice, but it does need to exclude distroseries which have been deselected on a per-recipe basis, and ignore "Failed to upload" errors to be truly useful. | 14:22 |
| dOxxx | good morning | 14:23 |
| maxb | otherwise there is too much red there which cannot be made to go away | 14:23 |
| * jelmer_ waves | 14:25 | |
| dOxxx | anybody know how to get a bzr config object from a working tree? | 14:25 |
| jelmer_ | whoever highlighted me here a couple of minutes ago, please do so again | 14:26 |
| jelmer_ | I seem to've hit a unity+xchat bug so I can see that I have highlights, but my xchat window doesn't appear | 14:26 |
| maxb | jelmer: Your recipe-status page is rather nice, but it does need to exclude distroseries which have been deselected on a per-recipe basis, and ignore "Failed to upload" errors to be truly useful. | 14:30 |
| maxb | otherwise there is too much red there which cannot be made to go away | 14:30 |
| jelmer_ | maxb: The "Failed to upload" errors should nowadays be avoidable, as you can request the daily build to run (rather than just having the recipe build) | 14:31 |
| maxb | you can? | 14:31 |
| jelmer_ | AIUI the performDailyBuild() API call does so | 14:33 |
| maxb | hm, but not in the gui? | 14:34 |
| jelmer_ | The interface in the UI has changed recently so there is a "Build now" button on daily build recipes | 14:34 |
| jelmer_ | I'm not sure whether hitting that does the same thing though. | 14:35 |
| exarkun | What's supposed to be in C:\Users\username\AppData\Roaming\bazaar\2.0\subversion.conf? | 14:44 |
| jelmer_ | exarkun: bzr-svn settings per svn repository; e.g. what the repository layout is | 14:45 |
| exarkun | hm, ok | 14:46 |
| exarkun | I guess at least some of that is auto-generated | 14:46 |
| jelmer_ | actually, s/bzr-svn/bazaar/. You can also set things like "email" if you want to override them on a per-svn repository basis | 14:46 |
| exarkun | the contents of this one got erased somehow and bzr got upset | 14:47 |
| jelmer_ | exarkun: oh, how? | 14:47 |
| exarkun | but now that I've deleted the file entirely, it's working again, and there's some new stuff in it | 14:47 |
| exarkun | beats me | 14:47 |
| jelmer_ | exarkun: I can see it getting upset if the syntax is invalid, but it should work fine without a subversion.conf file | 14:47 |
| exarkun | I would _guess_ something to do with crummy filesystems and power failure | 14:48 |
| exarkun | yea, it was complaining about a syntax error | 14:48 |
| exarkun | hopefully bzr-svn doesn't rewrite that file unless something in it really needs to change? | 14:49 |
| jelmer_ | exarkun: it shouldn't - it uses bzr's .conf parsing/generating infrastructure | 14:50 |
| exarkun | I'd hope a filesystem wouldn't lose data that wasn't written out very soon before a crash. But it's Windows so who knows. | 14:50 |
| exarkun | but it's working now. thanks. | 14:51 |
| mgz | it's okay, windows doesn't run ext4. | 15:04 |
| jelmer_ | hi mgz, thanks for that alpha fix | 15:12 |
| mgz | I thought after I posted it you might have wanted it on the 2.3 branch. | 15:12 |
| mgz | Or perhaps cunning debian ways are enough. | 15:13 |
| jelmer_ | Yeah, I've added it as a debian patch for the moment. | 15:14 |
| jelmer_ | I guess it would be appropriate for 2.3.1, but I'll leave that up to our friendly RM | 15:14 |
| jelmer_ | maxb: all of the existing failed to upload errors should go away once new upstream revisions land afaict | 16:06 |
| maxb | yes... but that can take years sometimes | 16:21 |
| maxb | *cough* bzr-cvsps-import *cough* | 16:21 |
| jelmer_ | hehe | 16:32 |
| maxb | Hmm. Looks like .performDailyBuild() isn't exposed on prod yet | 16:52 |
| jelmer_ | maxb: it is - try flushing your caches | 16:52 |
| maxb | ah, so it is | 16:53 |
| maxb | oddly | 16:54 |
| maxb | As it seems to have returned a list of dicts, rather than a list of SPRB objects | 16:54 |
| caravel | salut | 16:54 |
| jelmer_ | hi caravel | 16:56 |
| caravel | two questions today :) 1. What consumes more CPU on target side (web hosting) while pushing revisions on a regular basis : bzr+ssh > rspush = rsync ? Using bzr for code only, and then also for images ? | 16:56 |
| caravel | and | 16:56 |
| caravel | I'm a KDE user, searched everywhere for some basic integration to Dolphin. Subversion sits here in my context menu, I didn't even ask, rather cool.... all I found for bzr is this http://forum.kde.org/brainstorm.php#idea82915_page1 and this http://kde-apps.org/content/show.php/Bazaar-Servicemenu?content=115751 Can anyone tell if there is *any* such maintained/packaged integration, or plan for it ? | 16:57 |
| jelmer_ | caravel: I'm not aware of any dolphin integration plans. I agree it'd be nice to see, though | 16:57 |
| * caravel is running Fedora 14 (x86_64), if it ever matters | 16:58 | |
| jelmer_ | caravel: qbzr is pretty good, and there is also bzr explorer which is a custom file browser on top of qbzr | 16:58 |
| caravel | jelmer_: thanks. Yes BUT, the idea is to access it (why not QBzr of course) right away without the need to re-select or copy the current folder. Simple but sooo nice. Should try the servicemenu route as enlighten in my link above, then ? Anyone done this before with a recent KDE version ? | 17:00 |
| caravel | *highlighted | 17:01 |
| jelmer_ | caravel: I haven't seen anybody work on something like that | 17:01 |
| caravel | jelmer_: I was told my the person I am trying to help... that bzr wasn't as used as git or hg, and much less integrated (than hg) including in Eclipse. Maybe, these would be rather easy efforts to attract more users ? | 17:02 |
| * caravel is NOT scared by command lines, rather the opposite okay ;-) | 17:03 | |
| jelmer_ | caravel: there is a eclipse plugin for Bazaar, but there's only a couple of core developers and only so many hours in the day | 17:03 |
| caravel | and yes, I know "most users" are on Windoz and therefore, already have the benefits of TortoiseBzr and others | 17:03 |
| maxb | And programming Eclipse plugins is a whole skill set to itself, not one you go and pick up just to attract users | 17:04 |
| caravel | jelmer_: yes, sure, I know -- I haven't tried the Eclipse plugin yet myself, will tomorrow, but I trust what that person (which I'm trying to advise) told me about that Eclipse plugin in comparison to what he saw with hg | 17:04 |
| jelmer_ | caravel: I'm not denying that the eclipse plugin could be improved significantly :) | 17:05 |
| caravel | maxb: ok ok I'm not trying to be offending :) just encouraging. Eclipse is massively popular today, lots of people try it just because it's so popular and extendable | 17:06 |
| caravel | the result is, that person, who I advertise bzr to, had the impression bzr is not so cool (as hg) | 17:06 |
| maxb | caravel: What you say is true. Unfortunately, I don't see any way to remedy it | 17:07 |
| maxb | Unless someone who likes writing Eclipse plugins gets very enthusiastic about Bazaar | 17:07 |
| maxb | The time I briefly looked at Eclipse dev made me run away. Fast. | 17:08 |
| * caravel has never looked at Eclipse plugins internals, either.. | 17:08 | |
| maxb | I face exactly this issue in promoting bzr at work | 17:08 |
| maxb | Where I am currently forced to use svn | 17:09 |
| caravel | I suspect that getting something plug and play for Dolphin, should be easy, basing it on Subversion's integration - right ? | 17:09 |
| maxb | A question only someone familiar with KDE programming could answer. | 17:10 |
| caravel | maxb: sure | 17:10 |
| maxb | I've never even run it, let alone looked at its APIs | 17:10 |
| caravel | could anyone give a some clues about my question 1, cf CPU consumption ? | 17:10 |
| maxb | I don't have any actual figures, but I'd suspect bzr+ssh to be vastly better because it understands the structure of the data it is moving around | 17:11 |
| caravel | maxb: that's why I suggested the "equation" above, yes | 17:11 |
| maxb | The point is moot, however. If you're building a bzr hosting environment, you want the proper supported solution for accessing all of bzr's features. Not a hack that syncs trees unaware of the content | 17:12 |
| caravel | maxb: no no : the goal in our case, is to replicate web sites changes from testing env, so it is mainly pushing changes, we could even avoid to copy any history. | 17:13 |
| maxb | hrm. Have you seen bzr-upload? | 17:15 |
| caravel | maxb: right now we have only some jailed and restricted chroot, neither rsync not bzr are avail on the server, but we are requesting these | 17:15 |
| caravel | maxb: no, let me check this one, thanks for the pointer | 17:15 |
| maxb | That one is only really an option if you're *really* *really* sure no one will be directly modifying the files on the server | 17:16 |
| caravel | maxb: yes, I understand it works like rspush, i.e. if there were any changes in the mean time, it would fail | 17:17 |
| caravel | maxb: so we can't use that unless we first "check out" and diff eg. conf files from the server : the prod web server has a life, while we need to be revision these too | 17:19 |
| caravel | *need to revision* | 17:20 |
| caravel | Would the use of any "smart" method (bzr+ssh, or rspush or even simple rsync) result in saving not only traffic but also CPU, compared to "dumb" method (bzr push, bzr-upload over sftp) ? | 17:22 |
| caravel | since "smart" transfers are smaller, shorter, and since sftp also consumes some CPU... | 17:23 |
| * caravel is trying to find arguments to convince the hosting folks | 17:24 | |
| sbs | hi, I am new to bazaar, and would like to start using it with a svn repo | 17:53 |
| sbs | should I go with v2.2 or 2.3? | 17:53 |
| caravel | sbs: if you are new to *anything* you probably want to stick to the latest stable, in any case. Anyway, it's my thought | 17:57 |
| sbs | the down load page shows 2 stable 2.3.0 and 2.2.3 thus my question | 17:58 |
| caravel | sbs: I'm using Fedora and use official repos, hence I use ... 2.2.1! Latest stable on the download page is rather very fresh, if I wanted to download it I would give it a go, still, since it's said to be stable | 18:02 |
| sbs | I am under xp on the target system, so I went for V2.3 | 18:03 |
| sbs | trying to find back the 5s introduction to bzr page that explain the setting up of accounts and all | 18:03 |
| caravel | sbs: sounds a reasonable choice to me.. | 18:03 |
| maxb | sbs: The latest stable is 2.3.0. If you have a choice, you might as well use the latest. Though I don't think you'll miss much if you do end up using 2.2 | 18:03 |
| caravel | sbs: as per the doc, it hasn't been updated yet to reflect that 2.3 is now stable | 18:04 |
| sbs | my goal with bzr, it to have dcvs on machine with no net connexion while keeping the central repo with svn when connected | 18:04 |
| * caravel is going away for a while | 18:04 | |
| sbs | yeah the doc points to 2.5, I'll try to manage that :) | 18:05 |
| sbs | when I do a svn+https checkout, I get a copy of my svn repo | 18:39 |
| sbs | will committing in bzr commit to svn ? | 18:39 |
| sbs | what if there is no connectivity at the time of the commit? | 18:39 |
| caravel | sbs: can't tell sorry, but you could easily test this yourself, and very fast :) disable your connectiity ! | 19:29 |
| caravel | sbs: (if you're not sure how to do this, under xp go to network connections, right click your adapter(s) and hit disable) | 19:30 |
| sbs | repo = repository sorry | 19:55 |
| caravel | sbs: seems reasonable to use "repo" in this room :) | 19:56 |
| sbs | oops wonrg paste, I'll do ti again | 19:56 |
| sbs | can one create a clone of a repo to copy it offline to another computer (using a usb stick for example) ? | 19:56 |
| caravel | sbs: I'm just a beginner with bzr but I'm sure already that a standalone repo ca be moved/copied just as you wish, still you certainly want to branch it first if you wish to merge once that aother computer is online again | 19:58 |
| sbs | the other computer will never be online again that's my point | 19:58 |
| sbs | let me ty to explain | 19:58 |
| caravel | then yes, you can copy it back and forth, can't see why not, as long as you edit it once at a time | 19:59 |
| caravel | work from office, copy to usb, work from home... | 19:59 |
| * sbs thinks of the proper description for the workflow | 19:59 | |
| caravel | you may consider even better to sync faster : make your usb the "dumb" storage | 20:00 |
| caravel | and branch from it in both workstations | 20:00 |
| sbs | office Comp 1 bzr+svn to have a local copy of the svn repo, with mostly internet connection | 20:01 |
| caravel | then you can push to and update from, your usb stick | 20:01 |
| sbs | client comp 2 bzr nosvn no internet connectivity | 20:01 |
| sbs | I need to be able to code change on the comp2 either when there or over vpn connexion, and track changes | 20:01 |
| sbs | then create a patch I can apply on comp1 to keep the svn repo in sync | 20:02 |
| caravel | sbs: can't tell what bzr+svn do, did you try as I suggested, offline ? | 20:02 |
| sbs | bzr commit is local no svn communication | 20:02 |
| sbs | svn push does svn communication | 20:02 |
| sbs | bzr push sorry | 20:03 |
| caravel | from my understanding, you'd checkout on the PC you're connected, from svn... into your usb key | 20:03 |
| caravel | then from the offline pc you can bzr commit.. also to that key | 20:03 |
| caravel | then from the connected pc, you can additionaly svn push | 20:04 |
| caravel | .. back to the svn repo | 20:04 |
| caravel | using only the usb key if you wish, in all situations ! | 20:04 |
| sbs | I can't plug the usb stick when running in vpn mode | 20:04 |
| caravel | sbs: then you do the svn checkout on the connected pc, and you branch from it to the usb key | 20:05 |
| sbs | hold on | 20:05 |
| caravel | then on the offine pc, you can work off the usb stick, directly | 20:05 |
| caravel | and when you're back to the online pc, you push your changes to the "master" checkout branch | 20:06 |
| sbs | I will give it a shot, and do a couple tries, and read the manual a bit more a well | 20:06 |
| caravel | then you unplug your usb stick, connect to vpn and svn push your changes | 20:06 |
| sbs | does a bzr enabled computer expose some network services so that other machines can connect to it for checkout, commit.... | 20:15 |
| Peng | sbs: Typically you'd use SSH for that. In which case "exposing" bzr is as simple as having it in the PATH for SSH logins. | 20:33 |
| sbs | i don't usually use ssh | 20:33 |
| sbs | not in the *nix world | 20:33 |
| Peng | Wait what. | 20:34 |
| sbs | is there an ssh server/ client included in bsr? | 20:34 |
| lifeless | client yes, server no. | 20:34 |
| sbs | ok I'll rephrase. Once I have set-up a local repo that is bound to my central svn repo. How do I clone it to send it to some one not having internet access so that he can work on it and we can later merge | 21:17 |
| sbs | ? | 21:17 |
| lifeless | bzr branch source target | 21:18 |
| lifeless | where target is the location you are going to send to him (SD card or whatever) | 21:18 |
| sbs | source is the repo top folder? | 21:18 |
| lifeless | branch directory, yes | 21:18 |
| sbs | I get an error when I do this that says: | 21:18 |
| lifeless | branches get bound, not repositories | 21:18 |
| sbs | ok got it thks | 21:20 |
| aber | I have a question. How can I show the current revision? | 21:20 |
| lifeless | bzr revno ? | 21:21 |
| aber | :D | 21:21 |
| === Peng__ is now known as Peng | ||
| spiv | Good morning. | 22:55 |
| jelmer_ | hey spiv! | 22:56 |
| spiv | jelmer_: hmm | 23:20 |
| spiv | jelmer_: branching from svn seems much slower in lp:bzr vs. 2.3 | 23:20 |
| jelmer_ | spiv: hmm? | 23:20 |
| spiv | jelmer_: a glance at a couple of SIGQUIT tracebacks suggests it might be fallout from the changes introduced by my fetch-all-tags work | 23:21 |
| jelmer_ | spiv: Yeah | 23:21 |
| jelmer_ | spiv: I filed a bug about it earlier, it breaks bzr-git and bzr-hg | 23:21 |
| jelmer_ | looking at the graph is quite expensive for svn repositories and impossible for git/hg | 23:21 |
| spiv | Ah, I didn't notice those reports (yet) | 23:22 |
| jelmer_ | spiv: In particular with git and hg it should be possible for the repository to provide the heads to fetch, as they would already know what the relevant heads are. | 23:22 |
| spiv | jelmer_: hmm | 23:22 |
| spiv | jelmer_: s/repository/branch/ and I can help you with that ;) | 23:23 |
| spiv | jelmer_: https://code.launchpad.net/~spiv/bzr/branch-revs-to-fetch | 23:23 |
| jelmer_ | spiv: ah, neat | 23:26 |
| spiv | jelmer_: I'll turn that into a mp today | 23:27 |
| spiv | I needed it to fix bzr-loom | 23:27 |
| jelmer_ | ah, cool | 23:29 |
| jelmer_ | I was wondering about that, I noticed bzr-loom was broken.. | 23:29 |
| jelmer_ | spiv: so that only leaves the issue of the graph access during sprout, I think | 23:30 |
| spiv | Hmm | 23:32 |
| jelmer_ | spiv: https://bugs.launchpad.net/bzr/+bug/717937 | 23:32 |
| jelmer_ | there's a lot of "hmm" in the air today ;) | 23:32 |
| spiv | :) | 23:33 |
| spiv | The bzr-git/hg bugs suggest I made the wrong call restricting the type of the fetch_spec param to SearchResults | 23:33 |
| spiv | Because those are often produced by a graph search (e.g. "find what needs to be copied to transfer these heads into repo X") | 23:35 |
| jelmer_ | spiv: as long as it's just a recipe of the search that's being passed in it's probably fine | 23:36 |
| spiv | It sounds like bzr-git/hg would like to be able to resolve e.g. NotInOtherForRevs(..., heads_to_fetch) itself | 23:36 |
| jelmer_ | spiv: yep | 23:36 |
| spiv | "recipe" is a terribly confusing term in this context :) | 23:36 |
| jelmer_ | heh, indeed | 23:37 |
| jelmer_ | spiv: could we perhaps put that logic on the interrepo implementations? | 23:38 |
| spiv | maybe | 23:38 |
| spiv | Hmm, probably | 23:39 |
| spiv | Take a look at all the subclasses of AbstractSearch | 23:39 |
| spiv | Currently the only ones we have all involve a from_repo and a to_repo | 23:39 |
| spiv | I assume bzr-hg/git support the concepts of "fetch every rev from source that target doesn't already have", "fetch all revs for $heads from source that target doesn't already have"? | 23:41 |
| spiv | (and for that matter "fetch all of source" and "fetch all revs for $heads from source") | 23:42 |
| jelmer_ | spiv: yep | 23:43 |
| jelmer_ | and a specific network protocol to discover roughly which revisions to fetch based on that indication | 23:43 |
| spiv | Ok. | 23:43 |
| spiv | I'm a unsure atm how best to adjust the API to accomodate this. | 23:44 |
| jelmer_ | the client doesn't have access to the revision graph on the server, it just tells the server which heads it wants and then the server asks the client for a bunch of specific revisions if it has them. | 23:44 |
| spiv | Perhaps you should take a stab at it as you're closer to the use cases :) | 23:45 |
| jelmer_ | Yeah, I'll have a look tomorrow. I haven't looked closely yet.. mainly just noticed that it's broken | 23:47 |
| spiv | jelmer_: ok, great :) | 23:50 |
| spiv | I've quickly dumped a summary of this chat in the bug | 23:50 |
| lifeless | jelmer_: can you describe the set of tags as things you want ? | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!