| spiv | rhkfin: perhaps you want the 'bzr-upload' plugin? | 00:20 |
|---|---|---|
| === naoki-away is now known as naoki | ||
| Manganeez | mathrick: the problem does indeed seem to be the back-port commits into the 2.7.1 tag in my scenario. I'm having trouble thinking of a way around it. | 00:44 |
| mathrick | Manganeez: I don't think any exists | 00:46 |
| mathrick | backports are indistinguishable from conflicting edits | 00:46 |
| Manganeez | In dreamland, where I live, I'm imagining somehow backing out all of the backport commits by rolling back to the rev when the tag was originally created, then merging to the new tag. | 00:48 |
| mathrick | that might be possible | 00:53 |
| mathrick | though it'd likely be somewhat involved | 00:54 |
| Manganeez | Seems like that falls into the "rewriting history" category, though | 00:54 |
| mathrick | Manganeez: yes, but it might be possible to coerce pipes / rebase into doing just that somehow | 00:55 |
| mathrick | I'm not exactly sure, though, I don't have a very good grasp of how pipes work | 00:55 |
| mathrick | I just know they somehow result in rewritten history without actually having done that | 00:55 |
| mathrick | Manganeez: http://wiki.bazaar.canonical.com/BzrPipeline <-- maintaining patches on top of upstream branches is one of the listed use-cases | 00:58 |
| Manganeez | Reading that now... :P | 00:59 |
| Manganeez | also hadn't heard of bzr-pipes. Like I said, <-- n00b | 00:59 |
| mathrick | since it works even with tarballs, which have 0 history, svn should be handled with no problems :) | 00:59 |
| mathrick | Manganeez: pipes are hot new tech, I don't understand it myself yet | 00:59 |
| Manganeez | the stacking seems a bit like loom, another thing I don't quite get | 01:00 |
| mathrick | yes, looms are similar | 01:03 |
| igc | morning | 01:08 |
| === naoki is now known as naoki-away | ||
| === naoki-away is now known as naoki | ||
| lifeless | morning igc | 01:29 |
| igc | hi lifeless | 01:30 |
| * mwhudson is amused to note that hosting weave branches on launchpad has been really broken for a long, long time | 02:09 | |
| mwhudson | or any all-in-one format | 02:09 |
| Manganeez | <-- n00b still catches himself thinking subversiony | 02:16 |
| Manganeez | mathrick (if you're still there): based on experimentation, it's really seeming like the easiest way to track vendor svn development is to *not* have bzr-svn installed. Instead, just have a hybrid repo where you svn sw & bzr commit. Branch from that for customization branches. | 02:23 |
| Manganeez | If it's installed, bzr-svn intercepts and prevents that from working. | 02:23 |
| Manganeez | for centralized repo, branch from mirror to create the centralized, and branch from *that* for customization work. | 02:25 |
| Manganeez | never push back to vendor mirror | 02:25 |
| Manganeez | It just seems like, in spirit, bzr-svn should provide a way that's *easier*, not step on existing possibilities to make it *harder* | 02:26 |
| Manganeez | anyone: is there a way to get a diff between the current branch and the parent branch? Which I think is the same as asking for the diff that would be applied if I pushed? | 02:41 |
| spiv | Manganeez: "bzr diff :parent", although if the branches have diverged then "bzr diff -rancestor::parent" is probably more helpful. | 02:43 |
| spiv | You may also find "bzr merge --preview" to be helpful | 02:43 |
| Manganeez | ah, thanks spiv. I also just figured out how to do it with "--old" | 02:44 |
| spiv | :parent is a location alias, "bzr help location-alias" or http://doc.bazaar.canonical.com/bzr.2.1/en/user-reference/location-alias-help.html | 02:44 |
| Manganeez | "bzr diff :parent" produced no output. I think the old/new logic is just reversed from what I was looking for (parent had no missing changed for me, only the other way around). "bzr diff --old :parent" works. | 02:47 |
| Manganeez | Basically, I want to see my customizations vs. my parent vendor-tracking mirror. | 02:47 |
| === oubiwann` is now known as oubiwann | ||
| === naoki is now known as naoki-away | ||
| === naoki-away is now known as naoki | ||
| lifeless | spiv: spm: https://code.edge.launchpad.net/~gz/bzr/kindness_to_FAT_and_other_utime_stories_epilogue/+merge/23545 | 05:14 |
| lifeless | merged by pqm, zaroo email involved | 05:14 |
| lifeless | note the bug at the end :P | 05:14 |
| === khmarbaise_ is now known as khmarbaise | ||
| igc | back | 06:42 |
| lifeless | front! | 06:48 |
| * joyer | 06:58 | |
| joyer | is there new plan to boost bzr's first time clone's low speed & memory exhausted? | 07:01 |
| joyer | every time a clone emacs repo...The whole system hung up(386M memory unbuntu). | 07:02 |
| mwhudson | joyer: i filed a but about that last week | 07:07 |
| mwhudson | bug | 07:07 |
| mwhudson | joyer: https://bugs.edge.launchpad.net/bzr/+bug/562666 | 07:08 |
| ubottu | Launchpad bug 562666 in bzr "2a fetch is very cpu intensive" [High,Confirmed] | 07:08 |
| lifeless | joyer: this is cloning over the network or locally ? | 07:09 |
| igc | lifeless: :-) | 07:14 |
| rhkfin | spiv: bzr-upload, will check, thanks! | 07:19 |
| joyer | lifeless: over network. | 07:20 |
| lifeless | joyer: from which host ? | 07:20 |
| joyer | 'v no idea. I'm from asia... and type this `bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk' | 07:21 |
| lifeless | ok, bzr.savannah.gnu.org - thats running plain http | 07:22 |
| lifeless | so will be slow and use a lot of memory. | 07:22 |
| joyer | than my CPU will be drain out by bzr for 5 hours or so. | 07:22 |
| lifeless | This is a) expected, b) a fix will eventually be deployed, but its a configuration issue not a bzr bug | 07:22 |
| joyer | I see. there may be some storage architectur diff between git/hg/bzr... | 07:23 |
| joyer | but bzr seems need alot more memory | 07:23 |
| lifeless | joyer: all three performan suboptimally over plain http; they need a server side component to perform best | 07:23 |
| lifeless | joyer: try 'bzr branch lp:emacs' | 07:24 |
| poolie | hi lifeless | 07:24 |
| lifeless | joyer: its a mirror of the savannah branch, and should be faster and use less memory | 07:24 |
| lifeless | poolie: hihi | 07:24 |
| poolie | how's pqm? | 07:24 |
| lifeless | poolie: pretty good; launchpadlib is very very very slow; I have fixes for the UI for when spm gets back from a out-of-house thingy | 07:25 |
| poolie | ok | 07:25 |
| poolie | and other stuff? | 07:25 |
| lifeless | its happily merging from launchpad though | 07:25 |
| lifeless | which is great. One small glitch to wrap up and then its can be forgotten about - its not reporting quite right. | 07:25 |
| joyer | lifeless: i can tolerate the slowness. but memory consume too much.. why not cache out to disk?? | 07:25 |
| lifeless | various bugs looked at. | 07:25 |
| lifeless | joyer: caching out to disk happens via swap, naturally. | 07:26 |
| joyer | mwhudson: didn't notice it . i'wll check it . | 07:27 |
| lifeless | joyer: we dont' caching the bulk of the content. Because you're using HTTP though, more is being kept in memory than if you use a smart server url - like the bzr+ssh://bazaar.launchpad.net/~vcs-imports/emacs/trunk | 07:27 |
| lifeless | joyer: the bug mwhudson referenced isn't what you're suffering. | 07:27 |
| joyer | lifeless: I'm behand a big firewall~ | 07:27 |
| lifeless | joyer: do you have ssh access ? | 07:28 |
| joyer | lifeless: ok.. I'll take a look. | 07:28 |
| joyer | lifeless: no. a guess alot people at work are behind FW. | 07:28 |
| joyer | lifeless: I still hope bzr can run politely on low memory machine (like mine). I'll try hack on the source code, and write a patch.(that will be not short) | 07:30 |
| lifeless | joyer: we are working to reduce memory use | 07:31 |
| lifeless | joyer: but emacs is a very large repository | 07:31 |
| lifeless | joyer: how much memory do you have? | 07:31 |
| joyer | 386Mb | 07:31 |
| lifeless | that is a very small amount. | 07:32 |
| joyer | lifeless: emacs isn't the biggest repo..mozilla is bigger.. also linux kernel. | 07:32 |
| joyer | lifeless: bzr should scale up.. | 07:32 |
| lifeless | joyer: there are folk using bazaar on both of those as I understand it | 07:33 |
| lifeless | joyer: heck, current GNOME uses 300 MB or so just booting. | 07:33 |
| lifeless | joyer: We would like to be leaner on memory use, and there is some work going on. | 07:34 |
| joyer | lifeless: thanks for the info.. I'll check the source code to gain some prove.. | 07:36 |
| poolie | lifeless: maybe i should try that idea of dumping gc usage into apport | 07:41 |
| poolie | though maybe apport won't fit | 07:41 |
| lifeless | poolie: if we get apport MemoryError exceptions, then apport probably will | 07:42 |
| lifeless | OTOH by the time the exception handler runs, a lot of the memory may have been freed | 07:42 |
| vila | hi all | 07:45 |
| lifeless | eoding, time to pack | 08:04 |
| poolie | cheerio | 08:04 |
| poolie | hi vila | 08:04 |
| * joyerh | 08:17 | |
| napster | 'bzr lp:pull panther' returns 'permission denied public key' error :-( what to do? | 08:50 |
| spm | napster: wild guess, but did you perhaps mean: bzr pull lp:panther? | 08:50 |
| napster | spm, That what I meant, sorry for mistake :) | 08:51 |
| spm | heh, is cool. | 08:51 |
| C2H5OH | hi, is it possible to mix centralized and distributed workflow? | 10:22 |
| C2H5OH | for example, my work colleages all use bzr in a centralized manner (with checkouts) but I would like to use it as branches | 10:22 |
| fullermd | Sure. | 10:23 |
| fullermd | What you do in your workspace has no relation to what they do in theirs (and vice versa). | 10:23 |
| fullermd | 's kinda the basis of distributed right there ;) | 10:24 |
| C2H5OH | ok, so if I have a different branch and take care of merge myself, then it does not conflict with their linear histori, correct? | 10:24 |
| C2H5OH | ok, I found it | 10:28 |
| C2H5OH | unbind and bind might do the trick for me | 10:29 |
| fullermd | I'd avoid that, myself. It's coloring a bit outside the lines. | 10:30 |
| fullermd | I'm not really sure what you mean by 'conflict with their linear history', but work is work. | 10:31 |
| fullermd | They have to 'update' when they get a rev behind, or two revs. Or 50 revs. It doesn't much matter whether those revs are all on the mainline, or some of them are off to the right. | 10:31 |
| C2H5OH | I mean, centralized manner forces linear history | 10:31 |
| C2H5OH | (without merge commits) | 10:32 |
| C2H5OH | but I've read that bzr log hides merge commits by default | 10:32 |
| spiv | Right. | 10:32 |
| fullermd | Oh, not really. If you work purely in checkouts without ever using other branches, you won't (aside from some special cases) ever get any right-hand parents. | 10:32 |
| spiv | Also, the presence of merge commits on the mainline won't interfere at all with someone that is using "bzr up" etc. | 10:33 |
| fullermd | But that... what spiv said. | 10:33 |
| C2H5OH | ok, so then I should not be afraid of that | 10:33 |
| spiv | (And if they ever do "bzr commit --local" then they will in generate merge commits, i.e. commits with multiple parent revisions, anyway) | 10:33 |
| spiv | Definitely no need to be afraid. | 10:33 |
| C2H5OH | I'll have to read more docs | 10:35 |
| C2H5OH | in order to get familiar with the terms | 10:35 |
| C2H5OH | coming from git/mercurial does not make it easy | 10:35 |
| fullermd | It certainly presents different challenges than coming from CVS. | 10:37 |
| C2H5OH | back to work then | 10:38 |
| C2H5OH | thank you very much for your help | 10:38 |
| C2H5OH | ;-) | 10:38 |
| spiv | You're welcome! | 10:38 |
| bialix | hmm, C2H5OH perhaps russian guy | 10:59 |
| millun | hi | 11:03 |
| millun | how can i list files commited between revisions #3 and #15? | 11:04 |
| bialix | millun: bzr st -r3..15 | 11:11 |
| millun | thanks | 11:19 |
| === joyer` is now known as joye | ||
| === joye is now known as joyer | ||
| sven_sandberg | hi #bzr! i have a source tree with changes in two files, file1 and file2. i want to commit the changes in two different changesets: cs1 with changes in file1 and cs2 with changes in file2. i have ran 'bzr gci' and typed changeset comments for both files. but when i de-select file2 and commit only file1, the changeset comments for file2 are lost. | 13:02 |
| sven_sandberg | since we now have the nice feature that changeset comments can be saved when a commit is cancelled, would it be possible that we could save the comments also when a file is not included in the commit? | 13:03 |
| maxb | Sounds like cause for bug to be filed against bzr-gtk | 13:05 |
| sven_sandberg | maxb, thanks for confirming that. should bzr-gtk bugs be filed at https://bugs.launchpad.net/bzr/+filebug too? | 13:06 |
| maxb | I'd imagine it would be better to file against bzr-gtk not bzr | 13:06 |
| maxb | though that's driven by my _assumption_ that the existing commit comment saving is presumably in bzr-gtk | 13:07 |
| jelmer | maxb: it's in both bzr-gtk and qbzr | 13:07 |
| sven_sandberg | maxb, jelmer, iirc, before this was in any official versions, i had to use custom versions of *both* bzr and bzr-gtk in order to save commit comments. i'm not sure which one of them would need to be patched for this to work | 13:09 |
| === mrevell is now known as mrevell-lunch | ||
| sven_sandberg | ok, is it ok if i report it as a bzr-gtk bug? | 13:16 |
| jelmer | sven_sandberg: I really think the commit message saving should be moved into bzr core | 13:18 |
| sven_sandberg | jelmer, ok, so i'll report a bzr bug? | 13:19 |
| nitian | mathrick: i was merging this http://pastebin.com/95Hj6QTP and now it has continued merging again from the last data stored till now! | 13:19 |
| nitian | now i have got : Read from remote host bazaar.launchpad.net: Connection timed outnserting stream | 13:20 |
| jelmer | sven_sandberg: against bzr-gtk for now | 13:21 |
| sven_sandberg | jelmer, ok, will do | 13:21 |
| mathrick | nitian: looks like your network is hosed | 13:22 |
| nitian | mathrick: so should i cancel/kill the bzr merge | 13:24 |
| mathrick | nitian: dunno, didn't it error out? | 13:24 |
| nitian | mathrick: no it is still fetching revisions! | 13:24 |
| mathrick | then probably let it do that | 13:25 |
| mathrick | I don't understand why it'd be so slow, I get almost 2M/s here | 13:25 |
| nitian | mathrick: but i guess it has gone way beyond the original download size! | 13:25 |
| mathrick | nitian: then kill it? | 13:25 |
| mathrick | huh, that thing's large | 13:26 |
| === radoe_ is now known as radoe | ||
| === mrevell-lunch is now known as mrevell | ||
| === kirkland` is now known as kirkland | ||
| vila | jelmer: ping, regarding https://code.edge.launchpad.net/~jelmer/bzr/more-colo/+merge/23592 , it seems this mp has already changed from this morning | 14:50 |
| vila | jelmer: there are conflicts currently, still some None args (which I suspect are name=None) | 14:50 |
| vila | jelmer: I'd like to review it but given the above... I'm not sure it is stable :) | 14:51 |
| vila | jelmer: And I saw a branch_name instead of just name.. take your pick :) | 14:53 |
| nitian | mathrick: i did this http://pastebin.com/HxWTzx3b but i am getting this error: Read from remote host bazaar.launchpad.net: No route to host | 15:03 |
| MvG | vila: I've just replied to your review at https://code.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 and I'm here in case you want to comment. I'd be particularly interested in whether there was a misunderstanding with that cache remark of yours. | 15:27 |
| jelmer | vila: thanks for the comments, I'll have a look | 15:28 |
| vila | jelmer: k | 15:28 |
| vila | MvG: looking | 15:29 |
| vila | MvG: Wow, indeed, I misread | 15:30 |
| MvG | I realize I might have avoided a bit of spam to the LP merge tool by trying IRC first and writing the mail afterwards, but it's too late for that now... | 15:30 |
| MvG | vila: Glad that's solved then. I assume you now approve, so I'll wait for another approval. Thanks! | 15:31 |
| vila | MvG: wait :) | 15:31 |
| MvG | Sure. | 15:31 |
| MvG | After all, what else can I do instead of waiting... :-) But I'll stay tuned here as well. | 15:31 |
| vila | MvG: my remark still reflects a lack of docstring I think, it's a bit weird to have a parameter ignored like that and ISTM that specifying --author on the command line should take precedence above whatever default the log formatter is using | 15:33 |
| vila | MvG: may be we don't have the right infrastructure to handle that yet, | 15:33 |
| vila | MvG: but at least you should document that (a comment or a docstring is fine) | 15:33 |
| MvG | vila: Please expand ISTM | 15:33 |
| vila | It Seems To Me | 15:33 |
| MvG | If the command line wouldn't take precedence, there'd be little point in that whole patch. | 15:34 |
| vila | MvG: I'm downloading your branch to review it in place, obviously I miss some context here | 15:35 |
| reyman | hello | 15:35 |
| MvG | vila: My idea is that there are multiple facets to logs: one is general format, another is authors list, and others (maybe to be implemented in future) might include a distinction between real name, email or account name, or might include a choice between bug URLs, bug numbers or no bug references at all. You surely can think of many other ways to fine-tune any log. | 15:37 |
| vila | MvG: ooooh yes I can :-/ | 15:37 |
| MvG | vila: So I want --format to choose the format, --authors to choose whom to list as authors, and so on. That way I can tune the format to match my needs, without having to implement a new format for every combination of these aspects. | 15:37 |
| reyman | i'm starting a project with milestone on launchpad (ex lp:~sproject/1.0/1.0start for first milestone), i don't understand how i can push my code on this milestone, i try "push lp:~reyman64/sproject/1.0/1.0start" but bzr say : "bzr: ERROR: Permission denied: "Cannot create '1.0start'. Only Bazaar branches are allowed."" | 15:38 |
| vila | MvG: authors should be an option to the format | 15:38 |
| vila | MvG: bug we can't do that right now | 15:38 |
| MvG | reyman: Push to ~user/project/name and then register name as the branch for that series. Milestones don't have their own branches. | 15:38 |
| vila | MvG: you don't want every format to reimplement the author logic right ? | 15:39 |
| MvG | vila: Look at line 60 of the diff: I made it an option to the format. | 15:39 |
| vila | MvG: we're in agreement then | 15:40 |
| reyman | MvG, ok i try | 15:40 |
| MvG | vila: And no, I don't want to reimplement anything, that's why I want the logic in the base class and all derived classes inheriting from it. | 15:40 |
| === deryck is now known as deryck[lunch] | ||
| reyman | so MvG i have only one branch for one serie ... i cannot register multiple branche for one serie, isn't it? | 15:44 |
| MvG | reyman: You're correct. You can have any number of branches associated with the project, and many might be closely related to a specific series on the content level, but only one of them is the official branch for the series as launchpad lists it. | 15:45 |
| MvG | reyman: By the way: when you reach the milestone, you might want to tag it in bzr. That way users have easy access to it even when the series moves on towards the next milestone/release. | 15:45 |
| vila | MvG: yet, ShortLogFormatter use short_author which force who to be 'first', so ISTM that doing bzr log --short --authors=all won't work no ? | 15:46 |
| vila | MvG: Your test cheats to achieve that I think | 15:47 |
| MvG | vila: the authors method ignores the who if -authors is specified. I'm pretty sure I even tested this on the command line. | 15:49 |
| vila | MvG: Ha, right, damn I keep getting this backwards, please add a comment there ! | 15:50 |
| MvG | vila: Currently writing... :-) | 15:50 |
| vila | or may be just reverse the code so it's more obvious that 'who' is relevant only if _author_list_handler is None | 15:52 |
| reyman | So if i understand MvG , for example if i have 3 milestone for serie 1 : a, b , c . I have three branch 1a 1b 1c or only one branch 1 with tag for release a b c? | 15:54 |
| vila | MvG: sorry for the late comments... | 15:56 |
| MvG | reyman: The second one is the preferred setup, I guess. The first one is very svn-style, and might cause confusion in some cases. | 15:57 |
| MvG | reyman: Of course, you could also have a single branch "trunk", configured as the main branch for all your series... There are a million ways, but some are more common than others. | 15:57 |
| vila | MvG: bug one more thing: we try to always use keyword arguments as such, and the way to decide if an argument is a keyword one or a positional one is mostly based on whether it has a default value | 15:57 |
| MvG | vila: Is use of ReST-style ``name`` to mark identifiers in docstrings good practice? | 15:58 |
| vila | MvG: so, can you use short=Ture and sep=', ' in the short_author call | 15:58 |
| MvG | Sure. | 15:58 |
| vila | MvG: yes, not enforced but I think we are leading towards it, to be honest I think I use 'name' myself though | 15:59 |
| reyman | Mvg, i'm trying to have a layout like bzr :) So you have only one trunk branch for each serie , and you tag it . Which name you associate with trunk of each serie ? | 16:00 |
| vila | MvG: except when you use the :param name: construct where it's already clear that you're referring the parameter | 16:00 |
| vila | reyman: we use the series itself: lp:bzr/2.2 | 16:00 |
| vila | reyman: series is always plural (don't ask me why, I'm not a native english speaker :-) | 16:01 |
| MvG | reyman: The term "trunk" normally is per project, not per series. | 16:01 |
| MvG | reyman: Looking at https://code.launchpad.net/bzr and looking at the link targets as your browser displays them, you'll see that the 2.2 series branch is in fact lp:~bzr-pqm/bzr/2.2, i.e. belongs to user ~bzr-pqm, project bzr, branch name 2.2. | 16:03 |
| === bac` is now known as BradCrittenden | ||
| MvG | vila: pushing. | 16:03 |
| === BradCrittenden is now known as bac | ||
| MvG | reyman: The user is of course called bzr-pqm, not ~bzr-pqm. Sorry there. | 16:05 |
| reyman | ok thks :) one other question (the last), when lp:bzr/2.2 is ok , all bugs fixed (:p ), you merge it into trunk ? or in fact bzr/2.2 have trunk for parent, and milestone are only for bugs correction ? In this case, you merge bug correction into trunk AND bzr/2.2 ? | 16:07 |
| MvG | reyman: I'm not too involved with how the bzr project handles things, but I personally found the following useful for my own, smaller projects: start with a branch "trunk", and a series "1.0" using trunk as its main branch. Work on it, do milestones and releases numbered 1.0.x, improve the code, until things become reasonably stable. | 16:13 |
| MvG | reyman: Then when I want to work on a feature that might break that stability, I branch: I create a 1.0 branch off current trunk, and make that the main branch for the 1.0 series. I also start an 1.1 series having trunk as its main branch. New features go into trunk. Bug fixes should be written against 1.0 if possible, and I can merge the 1.0 branch into trunk from time to time. | 16:13 |
| MvG | In the past, I've created the new branch starting with the first release of a series. That caused a lot of troubles, though: people submit fixes against trunk, and it takes more work to get them into the release series. This is the reason why I suggest splitting stable and trunk branches only when you actually introduce new features. | 16:14 |
| MvG | vila: Have you read the new docsting and comments? Things better now? | 16:15 |
| vila | MvG: yup | 16:17 |
| reyman | ok MvG thx a lot for your help :) | 16:17 |
| MvG | lifeless: As you already did a review of its predecessor, would you like to review https://code.edge.launchpad.net/~gagern/bzr/bug513322-authors/+merge/23122 as well? | 16:20 |
| * MvG is afk for a while. | 16:22 | |
| seeg | hello | 16:31 |
| seeg | i have a small problem | 16:31 |
| seeg | sometimes when i push a repo, the transfer stops because of some reason. when i try to push again i get file locks and the repo becomes dirty | 16:32 |
| seeg | how to clean this mess up? | 16:32 |
| seeg | i mean other than removing the repo and branching it anew | 16:32 |
| maxb | I seem to remember that that error message actually *tells* you how to clear the locsk | 16:35 |
| === deryck[lunch] is now known as deryck | ||
| === beuno is now known as beuno-lunch | ||
| mathrick | seeg: bzr break-lock | 17:30 |
| seeg | ah, this is what i needed :) | 17:31 |
| seeg | mathrick, thanks ;) | 17:31 |
| mathrick | you're welcome | 17:32 |
| mkanat | spm: ping -- did you see my most recent request for info relating to the last two traces posted to the codebrowse hang bug? | 17:58 |
| === beuno-lunch is now known as beuno | ||
| === salgado is now known as salgado-lunch | ||
| blueyed | what should I do with http://pastebin.com/S4psCNhi ? | 18:47 |
| maxb | blueyed: line 9, "bzr: interrupted" - you Ctrl-C-ed it or it did that all by itself? | 18:49 |
| blueyed | maxb: I did it. | 18:50 |
| blueyed | but that should just revert to previous state. | 18:50 |
| blueyed | it feels like "bzr revert" deleting my files! | 18:50 |
| maxb | Did you do it because the 'bzr up' was taking far too long, or would it be worth moving aside the pending-deletion directory and trying 'bzr update' again? | 18:53 |
| seeg | what is this error: | 18:53 |
| seeg | bzr update | 18:53 |
| seeg | bzr: ERROR: Permission denied: "/home/przemek/Programming/Python/.bzr/branch-format": [Errno 13] Permission denied: u'/home/przemek/Programming/Python/.bzr/branch-format' | 18:53 |
| seeg | ah, ok, i got it :) | 18:53 |
| maxb | seeg: "Permission denied" of course. | 18:54 |
| seeg | yeah, i try to create a branch of files on my disk on a remote computer | 18:54 |
| seeg | somehow it's difficult | 18:54 |
| seeg | i do bzr branch xxx@xxx/path | 18:54 |
| seeg | but this doesn't create a working tree on the remote server | 18:55 |
| maxb | seeg: Please, don't obfuscate your commands. (I suspect you've changed the meaning of that one by over-obfuscation) | 18:58 |
| seeg | well, from my local machine i did bzr branch sftp://login@host/path/to/branch | 18:59 |
| midichlor | i am getting this error while $bzr add: bzr: ERROR: Could not acquire lock "/home/mid/project/.bzr/checkout/dirstate": (11, 'Resource temporarily unavailable') | 19:00 |
| midichlor | i think i accidently edited som file in .bzr | 19:02 |
| midichlor | what should i do? | 19:05 |
| blueyed | maxb: I will move it away and try again - but this is distracting / causing data-loss-fear. | 19:10 |
| maxb | blueyed: Well then, why not just back up your changes via a 'bzr diff' first, and be unfearful? | 19:11 |
| blueyed | maxb: done so. point remains: why doesn't ctrl-c revert/break the "bzr up"? | 19:14 |
| blueyed | why do I have to cleanup to dirs after that? | 19:14 |
| maxb | I am not aware of whether that is supposed to be necessary or not | 19:15 |
| blueyed | Also: "Conflict adding file blogs/rsc/js/debug.js. Moved existing file to blogs/rsc/js/debug.js.moved." is no conflict, if the file has the same content IMHO? new bug? reported already? | 19:15 |
| blueyed | maxb: me neither, but common sense is :D | 19:15 |
| blueyed | I'll file a new bug about the conflict when adding the same file, ok? | 19:17 |
| midichlor | maxb: could you help me too? | 19:18 |
| maxb | midichlor: Are you using Windows? | 19:18 |
| midichlor | maxb: no, ubuntu 9.10 | 19:18 |
| maxb | hmm | 19:18 |
| maxb | What does "lsof /home/mid/project/.bzr/checkout/dirstate" print? | 19:19 |
| maxb | Is NFS or Samba or anything like that involved? | 19:19 |
| midichlor | maxb: no. i havent been dealing with any of the above | 19:20 |
| midichlor | maxb: http://pastebin.com/KWnk4LfF | 19:22 |
| maxb | Find and close both of those processes (one "bzr" and one "editor") | 19:22 |
| midichlor | maxb: as in kill 15225 ? | 19:25 |
| maxb | If necessary, but better would be to find the open editor session and quit it cleanly, if you can | 19:26 |
| RumblePure_ | hi lifeless. | 19:30 |
| blueyed | Hi | 20:24 |
| === salgado-lunch is now known as salgado | ||
| wilx | Hi. | 21:13 |
| wilx | I am slightly confused about Bazaar. Is each working copy a branch effectivelly or does it some concept closer to Subversion branches? | 21:14 |
| lifeless | wilx: each time you run 'branch' or 'push' you're making a branch (or updating a branch) | 21:17 |
| === khmarbaise_ is now known as khmarbaise | ||
| LeoNerd | Hrm... I just 'rebase'd in the wrong direction... | 22:32 |
| LeoNerd | I don't suppose there's any nice easy way to fix that, is there? | 22:33 |
| LeoNerd | Ah. OK.. managed to fix by some cunning branch/replays... probably broken its hash now but I doubt anyone (else) has it checked out | 22:38 |
| lifeless | LeoNerd: bzr heads --dead; bzr pull . -rrevid:oldhead | 22:47 |
| LeoNerd | Ahyes, that would have done it too | 22:49 |
| === salgado is now known as salgado-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!