| dacresni | are there any bottle necks identified in bzr > | 00:02 |
|---|---|---|
| dacresni | ? | 00:02 |
| ubotu | New bug: #209025 in bzr "ignore local changes" [Undecided,New] https://launchpad.net/bugs/209025 | 00:16 |
| schierbeck | jamesh: hey james -- do you know of any bzr-avahi gutsy debs lying around? | 00:20 |
| elijah | Can bzr merge multiple branches into the current one at once (i.e. an octopus merge, in git-speak)? | 00:23 |
| jelmer | elijah: technically yes | 00:25 |
| jelmer | elijah: but I think the UI doesn't make it easy at the moment | 00:26 |
| elijah | How does one do so? | 00:26 |
| elijah | (feel free to point me at the docs if they're around somewhere) | 00:27 |
| jelmer | elijah: The first branch you merge you can use regular merge for | 00:28 |
| jelmer | for subsequent merges, specify --force (otherwise it'll complain about the working tree having uncommitted changes) | 00:28 |
| elijah | ah, so you simply don't commit between merges, and force the 2nd, 3rd, etc. merges. Is that right? | 00:29 |
| jelmer | elijah: yep, exactly | 00:30 |
| elijah | sweet, thanks. | 00:30 |
| ubotu | New bug: #209046 in bzr "Crash when comitting with non-English description" [Undecided,New] https://launchpad.net/bugs/209046 | 02:35 |
| Peng | 1.3 will be out March 20th? Wow! | 03:11 |
| rolly | only 346 days left | 03:19 |
| jdong | rolly: never worry! Maybe my branch on LP will have refreshed by then! | 03:30 |
| jdong | (kidding, kidding :D) | 03:30 |
| abentley | Peng: Maybe it's an announcement that 1.3 *is* out, as of 20 Mar? | 07:52 |
| Peng | It was set on 20 Mar, so maybe you're right. | 07:53 |
| * Peng wanders off. | 07:53 | |
| === unenough_ is now known as unenough | ||
| === doko_ is now known as doko | ||
| Cheba | Hello. | 11:22 |
| Cheba | I've seen several times "bzr+http" mentioned here and there on the net. But can't find any info about that. Is there anywhere docs on that? | 11:23 |
| === thekorn_ is now known as thekorn | ||
| mc__ | How do you resolve your conflicts? May you recommend me a good tool? | 12:05 |
| RAOF | mc__: Meld is quite a nice graphical diffing tool, but I tend to just rummage through in emacs. | 12:08 |
| bob2 | smerge-mode is quite cool | 12:08 |
| mc__ | I'm not an emacs user though. | 12:09 |
| bob2 | people use vimdiff, too | 12:09 |
| matthewlmcclure | Hi, I'm using Bazaar on Cygwin with a Windows diff program. | 15:08 |
| matthewlmcclure | I had to edit the Bazaar source to make it work since the Windows program doesn't understand symlinks. | 15:09 |
| matthewlmcclure | Is there a better way? | 15:09 |
| jelmer | matthewlmcclure: I think there is a plugin | 15:12 |
| matthewlmcclure | jelmer, I see "win32symlinks". Is that it? | 15:18 |
| phanatic | matthewlmcclure: it is that | 15:20 |
| matthewlmcclure | Thanks. I'll give it a try. | 15:22 |
| jelmer | hey phanatic | 15:30 |
| jelmer | phanatic: does bundlebuggy work again for you? | 15:30 |
| phanatic | hey jelmer, it does :) i've just merged those requests... | 15:30 |
| matthewlmcclure | Hm... I think win32symlinks isn't what I need. It looks like win32symlinks is for avoiding file copies on Win32-native bzr | 15:31 |
| phanatic | jelmer: sorry, but i'm not used to this workflow yet, and i don't always get right who has to merge. | 15:32 |
| matthewlmcclure | My trouble is that my Windows-native diff program doesn't understand the symlinks created by Cygwin bzr. | 15:33 |
| jelmer | matthewlmcclure: there's not really a way around that I think | 15:35 |
| jelmer | phanatic: Thanks for merging them | 15:35 |
| jelmer | phanatic: Basically, the idea is that the submitter merges the merge request once it is approved | 15:35 |
| jelmer | unless the submitter doesn't have commit rights, in which case the second approver merges it | 15:35 |
| jelmer | at least, that's what's done for bzr.dev and I think it makes sense for bzr-gtk as well | 15:36 |
| Cheba | matthewlmcclure: use something that works under cygvin. Say, vim diff. There is no other way. | 15:36 |
| phanatic | jelmer: thanks for the clarification | 15:36 |
| matthewlmcclure | I'd like to offer a patch to bzr to make my use case work. I think I have to make bzr use file copies instead of symlinks. | 15:40 |
| Cheba | That won't work. | 15:41 |
| jelmer | schierbeck: hi | 15:45 |
| matthewlmcclure | Cheba: do you mean it won't work at all? Or that symlinks are preferrable when they work, so you won't accept a patch that stops using symlinks on Cygwin. | 15:45 |
| Cheba | First you'll have to mainatain symlink index somewhere so bzr know if it have to commit changes in symlink-copy file. | 15:47 |
| Cheba | Second you'll have to deal with the case when original file and symlink are edited separately and has different changes. | 15:48 |
| Cheba | While first is rather simple to deal. The second case is a big break in symlink idea. | 15:49 |
| schierbeck | jelmer: hi | 15:51 |
| schierbeck | jelmer: i read up on some of the sprint notes -- you guys were talking about signed revisions in bzr-gtk? | 15:54 |
| jelmer | schierbeck: Yep, we talked about that a little bit | 15:55 |
| schierbeck | jelmer: i've got a branch implementing the basic stuff in lp:~dasch/bzr-gtk/signatures/ | 15:55 |
| jelmer | the ability to sign revisions from gcommit and the ability to display signatures in bzr viz as we discussed on the list earlier | 15:55 |
| jelmer | schierbeck: ah, cool | 15:55 |
| schierbeck | it's very basic; it just informs the user whether the revision has been signed or not, and if so, if the signature is trusted | 15:56 |
| schierbeck | i don't even think i got the icon installation working | 15:56 |
| schierbeck | you're more than welcome to play with the code and make changes, i have exam the next week, so i'm kind of busy | 15:56 |
| schierbeck | *exams | 15:57 |
| jelmer | oh, ok | 15:58 |
| jelmer | schierbeck: btw, you mentioned wanting to discuss the future direction of bzr-gtk | 15:58 |
| jelmer | would now perhaps be a good time? phanatic also appears to be around | 15:58 |
| matthewlmcclure | Cheba: doesn't windows-native bzr have to solve the second problem already? Forgive me, I'm not very familiar with the code yet. | 15:58 |
| schierbeck | jelmer: yeah, i have some time now | 15:58 |
| jelmer | matthewlmcclure: Windows native doesn't support symlinks either | 16:00 |
| phanatic | me too :) | 16:00 |
| jelmer | cool :-) | 16:00 |
| schierbeck | awesome :) | 16:00 |
| schierbeck | well, i'd better start then | 16:00 |
| schierbeck | my main concern is what our product should be | 16:00 |
| schierbeck | should we keep the status qou -- i.e. a bunch of loosely couple utility programs? | 16:01 |
| schierbeck | or should we try to integrate them more tightly -- i.e. buff up the viz | 16:01 |
| schierbeck | erm, status "quo" | 16:01 |
| Cheba | matthewlmcclure: it doesn't. It just complies that platform doesn't support symbolic links. | 16:02 |
| jelmer | From my POV it makes sense to have bzr-gtk as a set of utility apps that can be reached from a couple of places - i.e. from GNOME, olive or the command-line. | 16:02 |
| jelmer | GNOME being the nautilus integration, task bar, preferences | 16:02 |
| schierbeck | jelmer: i agree that our widgets should be generalized in order to fit into different contexts, such as olive, nautilus and the viz | 16:03 |
| schierbeck | but i'm not sure about the command line -- do we really need to provide gui versions of *all* commands? | 16:03 |
| matthewlmcclure | cheba, jelmer: right, so I think if bzr had a workaround for Cygwin that "Cygwin doesn't support symbolic links", bzr would satisfy my use case. | 16:03 |
| schierbeck | i mean, what does gpull provide that plain pull doesn't? | 16:04 |
| schierbeck | i think we need to beware of command pollution | 16:04 |
| jelmer | schierbeck: Pops up a dialog that allows you to select a branch | 16:04 |
| schierbeck | well, true dat | 16:04 |
| jelmer | schierbeck: I don't think the fact it adds commands is really a problem | 16:05 |
| schierbeck | still, as a user of bzr-gtk, all i really need is the viz | 16:05 |
| phanatic | schierbeck: that's useful for olive, for example. so maybe just hiding it as a command would be okay, but please don't remove it :) | 16:05 |
| schierbeck | phanatic: don't worry, i'm not gonna go on a delete-frenzy :) | 16:05 |
| schierbeck | but i think we should perhaps consider whether anyone is actually using all those utility apps from the cli | 16:06 |
| jelmer | schierbeck: I'm happy to hide some of them | 16:06 |
| Cheba | matthewlmcclure: well, cygwin internaly handles symlink emulation so for all applications under cygwin those emulated symlinks look just like real. That's why I proposed to use tools that also run under cygwin. | 16:06 |
| jelmer | schierbeck: So they don't show up in "bzr help commands" but I don't see a reason to remove them alltogether. | 16:06 |
| jelmer | I use "bzr gpull" to test the pull dialog, for example. | 16:06 |
| schierbeck | jelmer: that sounds reasonable | 16:07 |
| phanatic | to me too... | 16:07 |
| jelmer | schierbeck: We could only make those commands visible that actually add something that's not present in their command-line equivalent | 16:07 |
| jelmer | such as gdiff / gcommit / viz | 16:07 |
| schierbeck | jelmer: exactly! | 16:07 |
| phanatic | jelmer: and gannotate | 16:08 |
| TFKyle | should probably add a help hidden-commands or something too imo | 16:08 |
| matthewlmcclure | Cheba, agreed, that would work; but it's a better user experience to be able to use Windows since I have all of Windows. I use Cygwin because I like it better than the Windows shell. I'm advocating better flexibility for the user to choose his own tools. | 16:08 |
| schierbeck | TFKyle: i think the hidden commands should be so peripheral to the average user that web documentation should be enough | 16:09 |
| TFKyle | schierbeck: I think it'd be useful still for debugging and/or making sure when you create a command in a new plugin that the name isn't already taken | 16:09 |
| schierbeck | TFKyle: that's true -- but perhaps have a central table on the bzr website with all command names is the optimal solution? | 16:10 |
| schierbeck | okay, i think we just need to sit down and sift through the commands -- should i just send in a list of commands i find irrelevant later on? | 16:11 |
| schierbeck | then we can discuss them individually | 16:11 |
| schierbeck | jelmer, phanatic: okay, the next thing on my mind is what the role of olive and nautilus should be | 16:12 |
| TFKyle | that's probably a good idea, though I'm slightly iffy on that being the only way to tell all of the hidden commands in your env out (sometimes I'm too lazy to go to the bzr website or offline (not so much, but I imagine a couple people are often enough)) | 16:12 |
| jelmer | schierbeck: btw, the signatures code looks very nice! | 16:12 |
| jelmer | schierbeck: Any chance you can make it optional though (hide the Signature tab if "import gpg" raises a ImportError) ? | 16:13 |
| schierbeck | jelmer: thank you -- still in its early stages, though. i need to go through the gtk icon docs. | 16:13 |
| schierbeck | jelmer: sure | 16:13 |
| TFKyle | mm, signed rev stuff in bzr-gtk will be nice | 16:13 |
| schierbeck | TFKyle: perhaps an environment variable? | 16:13 |
| jelmer | schierbeck: imho the various bits and pieces in bzr-gtk should be reachable from nautilus and/or other core ui's | 16:14 |
| jelmer | I don't think bzr-gtk should rely on GNOME (Nautilus) to be usable though | 16:15 |
| schierbeck | jelmer: i was more thinking: could we place all of olive's functionality in the nautilus plugin? | 16:15 |
| schierbeck | jelmer: yeah, but is anyone using olive outside gnome? | 16:15 |
| jelmer | schierbeck: that's already happened to the extent in which it is possible | 16:15 |
| jelmer | schierbeck: yes, it is perfectly possible to use olive without gnome | 16:16 |
| Cheba | matthewlmcclure: if anyone uses symlink I assume they know what they're doing. Say, I would newer rely on symlink if I'd know that this software have to run on windows. It's just because windows sucks and does not provide a way to define symlinks. | 16:16 |
| phanatic | schierbeck: i think olive should be improved, and i have some plans on that. it has its place as a tool - i talked to a few people at the sprint, and they told me that olive is not a bad approach at all, since there are similar tools for svn/cvs (cervisia, wincvs, etc.) | 16:16 |
| TFKyle | jelmer: havn't read the code, but you're saying the gpg module is part of gnome? seems odd | 16:16 |
| jelmer | TFKyle: where did I say that? | 16:16 |
| schierbeck | okay, i was just probing here. i think generalizing our widgets will improve all the bzr guis | 16:17 |
| Cheba | Though, AFAIK, NTFS has hardlinks which can ease emulation of symlinks. | 16:17 |
| schierbeck | TFKyle: we're running a dual-track discussion here | 16:17 |
| schierbeck | TFKyle: we'll merge them later on ;) | 16:17 |
| TFKyle | jelmer: heh, I assumed <jelmer> schierbeck: Any chance you can make it optional though (hide the Signature tab if "import gpg" raises a ImportError) ? and <jelmer> I don't think bzr-gtk should rely on GNOME (Nautilus) to be usable though were related, I likely suck though | 16:17 |
| jelmer | TFKyle: ah, yes - that was mixing two discussions | 16:18 |
| matthewlmcclure | Cheba, I think you're talking about symlinks inside a branch's working tree. My main issue is how bzr internally uses symlinks to make 'diff --using=' faster, more space-efficient. | 16:18 |
| jelmer | schierbeck: Yep, exactly | 16:18 |
| jelmer | schierbeck: We're already there to a large extent | 16:18 |
| jelmer | schierbeck: nautilus-bzr.py just imports dialogs from bzr-gtk and is itself very small | 16:18 |
| schierbeck | jelmer: yeah, although some widgets could be split into smaller ones, e.g. the revision view | 16:19 |
| Cheba | matthewlmcclure: oh... I see. | 16:19 |
| matthewlmcclure | sorry i wasn't clear before | 16:19 |
| schierbeck | jelmer, phanatic: what's your stance on the viz? should we make it more interactive? | 16:19 |
| schierbeck | i.e. add pulling, pushing, merging, committing? | 16:20 |
| phanatic | schierbeck: in fact that would make it similar to olive, but revision based instead of file based :) | 16:21 |
| jelmer | schierbeck: Adding the ability to open the pull / push dialogs from viz sounds like a good idea to me | 16:21 |
| schierbeck | phanatic: exactly -- but those are two very different workflows! | 16:21 |
| jelmer | schierbeck: although that's already possible somewhat too | 16:21 |
| jelmer | schierbeck: Merge and Commit I'm less sure about | 16:21 |
| schierbeck | jelmer: i don't think the viz is updated with the new revisions, so you still have to restart | 16:22 |
| phanatic | schierbeck: my plan is to actually merge the two workflows. so you can switch quickly between revision and file based views... | 16:22 |
| jelmer | allowing "bzr merge" and "bzr commit" inside viz is kinda pointless imho since those two operations require you to do working tree operations | 16:23 |
| schierbeck | phanatic: just what i'm thinking -- but what should be merged into what? | 16:23 |
| jelmer | schierbeck: that's a bug :-) | 16:23 |
| schierbeck | jelmer: i don't see why -- you most likely have a terminal window open anyways, since that's the only way i know of to open the viz outside of olive | 16:24 |
| phanatic | schierbeck: i don't really care to be honest :) | 16:24 |
| schierbeck | phanatic: well, you know i love the viz :D | 16:24 |
| schierbeck | phanatic: if we could provide the file view as a widget, that would be awesome | 16:25 |
| phanatic | schierbeck: yeah, that's why - i don't want to fight about this tiny little detail :) | 16:25 |
| phanatic | schierbeck: yeah, sounds sane | 16:25 |
| schierbeck | okay, i guess we should commence work on that soon, then | 16:28 |
| schierbeck | btw phanatic, jelmer: i've been reporting loads of bugs on launchpad, many related to merge proposals -- when that works well, and email support has been added, would you be interested in moving merge proposals to lp? | 16:29 |
| phanatic | schierbeck: bundlebuggy coming to launchpad? :P | 16:30 |
| jelmer | schierbeck: I'm a little bit concerned about having viz as a full bzr frontend | 16:30 |
| schierbeck | phanatic: exactly! | 16:30 |
| jelmer | schierbeck: to me it's mainly a revision browser | 16:30 |
| schierbeck | phanatic: i think they're working on it | 16:31 |
| jelmer | schierbeck: as long as it doesn't require me to use a web ui, I'll happily consider launchpad | 16:31 |
| phanatic | schierbeck: it would be better, since unfortunately our current bb instance switches off sometimes :/ | 16:31 |
| schierbeck | jelmer: i don't think we need to go full right away -- we could start with pull/update, which seems reasonable in a browser | 16:31 |
| schierbeck | jelmer: yeah, they have plans for email control | 16:32 |
| schierbeck | jelmer: bug #202003 covers this | 16:33 |
| ubotu | Launchpad bug 202003 in launchpad-bazaar "Should be able to review merge proposals over email" [Medium,Confirmed] https://launchpad.net/bugs/202003 | 16:33 |
| schierbeck | when the merge proposal workflow on lp is good enough, we can talk about moving to that | 16:34 |
| schierbeck | jelmer: i've also just made the signature tab optional | 16:34 |
| schierbeck | push as we speak | 16:35 |
| jelmer | schierbeck: Doh, I also did that.. | 16:35 |
| schierbeck | :) | 16:35 |
| jelmer | I've also moved the tab to a separate window | 16:35 |
| schierbeck | jelmer: do you want me to move the branch to ~bzr-gtk? | 16:35 |
| schierbeck | jelmer: in what sense? | 16:35 |
| jelmer | s/window/class/ | 16:37 |
| jelmer | schierbeck: Yes, if you could change the owner that would be useful | 16:37 |
| jelmer | schierbeck: unfortunately launchpad doesn't appear to be very fast implementating wishlist items :-/ | 16:37 |
| jelmer | not sure how much priority this has for them internally | 16:38 |
| matthewlmcclure | Would it be best if I open a bug in https://bugs.launchpad.net/bzr ? | 16:39 |
| jelmer | matthewlmcclure: about symlinks? | 16:39 |
| jelmer | matthewlmcclure: Is there a clear way to move forward? | 16:40 |
| matthewlmcclure | yes, re: symlinks. I'm not 100% clear on the best solution, but the symptoms are clear. | 16:41 |
| jelmer | matthewlmcclure: there's probably already a bugreport open | 16:42 |
| jelmer | matthewlmcclure: this is about being able to check out symlinks in working trees, right? | 16:42 |
| matthewlmcclure | jelmer: no, it's about 'diff --using=' not working when the arg to using is a Windows app, and bzr running in Cygwin. | 16:43 |
| schierbeck | jelmer: it seems to work :) | 16:43 |
| schierbeck | "change registrant" | 16:43 |
| schierbeck | jelmer: ~bzr-gtk/bzr-gtk/signatures | 16:43 |
| jelmer | thanks | 16:44 |
| matthewlmcclure | I think bzr needs to pass the physical path to the diff program instead of the symlink path. | 16:48 |
| Pilky | hey all, does anyone know if there's anyone doing anything along the lines of a Mac GUI client for bazaar? | 16:49 |
| jelmer | matthewlmcclure: ahhh, yes please file a bug | 16:50 |
| jelmer | Pilky: any reason for not using bzr-gtk or qbzr? | 16:50 |
| matthewlmcclure | will do. thanks. | 16:50 |
| Pilky | jelmer: I'm thinking more along the lines of a native Mac GUI client | 16:51 |
| schierbeck | wow, launchpad bzr operations are extremely slow today | 16:51 |
| schierbeck | Pilky: there are, to my knowledge, not any native ones | 16:51 |
| schierbeck | but if you'd like to write one... | 16:51 |
| Pilky | I might consider it at some point, the main issue would be finding time (and the fact that I only found out about bazaar yesterday ;) ) | 16:52 |
| schierbeck | Pilky: if you do, i'd be more than happy to help you if you have any questions | 16:53 |
| phanatic | Pilky: both qbzr and bzr-gtk work well on os x. and qbzr has native look. | 16:54 |
| Pilky | I think I'll play around with bazaar for a while and start using it on my apps to get used to it and then I might consider looking into a GUI client over summer | 16:55 |
| Pilky | phanatic: aqua buttons does not a native Mac UI make ;) | 16:56 |
| phanatic | textmate has a really good bazaar integration as well | 16:56 |
| Pilky | hmm, now that's more interesting | 16:56 |
| phanatic | Pilky: i know :) | 16:56 |
| Pilky | I have to say I knew that the background images on the Mac disk images are an extremely nice touch | 16:57 |
| Pilky | hell, having disk images on the official site for a vcs is a nice touch :P | 16:58 |
| phanatic | hehe :D | 16:59 |
| phanatic | i'm glad you like them ;) | 16:59 |
| jelmer | schierbeck: still there | 17:00 |
| jelmer | ? | 17:00 |
| Pilky | especially after spending most of yesterday fighting to get git to do something vaugly useful | 17:00 |
| jelmer | schierbeck: I think the signature branch is ready for merging | 17:00 |
| jelmer | I've added code to be able to find the icon path | 17:00 |
| phanatic | Pilky: of you have Leopard, you should have no problems getting it running after the install... | 17:00 |
| Pilky | phanatic: git ran, I just couldn't get my head around it, dunno why really | 17:01 |
| Pilky | bazaar just seems simpler and has nicer documentation | 17:01 |
| luks | you are not the only one who has that problem :) | 17:01 |
| phanatic | :) | 17:02 |
| * TFKyle was never able to wrap his head around git either | 17:02 | |
| Pilky | in fact the general mentality seems to fit my Mac mind, like it doesn't have to be the fastest, it just shouldn't be slow | 17:02 |
| jelmer | schierbeck: anyway, merge request sent :-) | 17:07 |
| jmehdi | I've just created a branch by doing "bzr init", "bzr add", "bzr commit" but now I'd like to know which files are under source control, is it possible? | 17:20 |
| jelmer | jmehdi: bzr st | 17:20 |
| jmehdi | it displays nothing... my "bzr add" didn't add anything?? | 17:21 |
| jelmer | sorry | 17:23 |
| jelmer | you need "bzr ls --versioned" | 17:23 |
| jmehdi | yep it's better ;) thanks! I should read the manpage as soon as I have time ^^ | 17:24 |
| LeiraHua | hi, everyone~ | 17:27 |
| LeiraHua | i wanna setup a bzr server for several of my firends | 17:27 |
| LeiraHua | i am trying to use sftp | 17:27 |
| LeiraHua | but i thing i don't quite understand, is the user access of sftp~ | 17:28 |
| === abadger1991 is now known as abadger1999 | ||
| LeiraHua | i have sftp enable by default on my ubuntu box~ but each user can access there own home dir~ | 17:28 |
| LeiraHua | even i can create a public dir which can be written by all these users, the files they create there are belong to themselves, which seems not so proper | 17:29 |
| LeiraHua | i think the bzr repo such as sftp://host/bzr, under this dir, all the files submitted by different users should have the same owner~ isn't it? | 17:31 |
| schierbeck | jelmer: awesome! | 17:34 |
| schierbeck | i'll take a look right away | 17:34 |
| LeiraHua | how can i setup an sftp bzr server, that all users use different user/passwd to login, but the files submitted on the server will have the same owner? | 17:34 |
| matthewlmcclure | jelmer, I opened a bug re: symlinks on Cygwin: https://bugs.launchpad.net/bzr/+bug/209281 | 17:35 |
| ubotu | Launchpad bug 209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,New] | 17:35 |
| LeiraHua | hello? | 17:37 |
| schierbeck | LeiraHua: i think that's an issue with the ftp server | 17:38 |
| LeiraHua | schierbeck: well, seems so, but is there any hint? | 17:38 |
| LeiraHua | i didn't find any howtos for this~ | 17:38 |
| schierbeck | LeiraHua: i'm sorry, but i haven't messed around that much with ftp and bzr | 17:39 |
| LeiraHua | schierbeck: then how did you setup your bzr repo? | 17:39 |
| schierbeck | LeiraHua: i generally use a smart server | 17:40 |
| schierbeck | bzr serve | 17:40 |
| LeiraHua | is it better? | 17:41 |
| schierbeck | it's faster, yes | 17:41 |
| schierbeck | and i think it's easier to set up | 17:41 |
| ubotu | New bug: #209281 in bzr "Windows diff apps don't understand symlinks created by Cygwin bzr diff --using" [Undecided,New] https://launchpad.net/bugs/209281 | 17:41 |
| schierbeck | jelmer: i think the text should be more elaborate in the sig tab. i'll take a look at it. | 17:42 |
| LeiraHua | schierbeck: good, thank you, i will check how to setup it~ | 17:42 |
| LeiraHua | schierbeck: BTW, besides the Bazaar User Guide, it there any other docs for smart server setup? any hint? | 17:45 |
| schierbeck | LeiraHua: try googling, i vaguely remember reading some tutorials | 17:46 |
| LeiraHua | schierbeck: thx~ googling~ | 17:47 |
| LeiraHua | schierbeck: i am still confusing, i've just read the smart server part of Bazaar User Guide. Smart server is invoked over ssh, from inetd, or in a dedicated mode. ssh which i can understand, but every is back to the start point, which i asked at first, that how to share the access control. but for the inet/dedicated mode, how can i control the access? | 18:09 |
| LeiraHua | schierbeck: how did you setup the smart server? | 18:10 |
| ubotu | New bug: #209299 in bzr "TestLongLogFormatter.test_author_in_log" [Undecided,New] https://launchpad.net/bugs/209299 | 18:20 |
| asabil | LeiraHua: I am not sure you can handle the access controle using inetd | 18:42 |
| LeiraHua | asabil: dose it mean, every one can access this bzr repo without any passwd? | 18:46 |
| LeiraHua | i just tested with the dedicated mode, seems so~ | 18:46 |
| asabil | yep | 18:46 |
| asabil | the only to have access control is through ssh | 18:46 |
| asabil | or using a dummy transport like sftp/rsync | 18:47 |
| asabil | LeiraHua: if you have a team, you can create a folder with a sticky bit on it | 18:47 |
| asabil | and put your branches there | 18:47 |
| asabil | and make the team part of the same group | 18:48 |
| LeiraHua | sticky bit~ | 18:50 |
| LeiraHua | just recall that~ thank you asabil~ | 18:53 |
| jelmer | schierbeck: cool, thanks | 19:11 |
| LeiraHua | asabil: if i add a sticky bit on this dir, dosen't it mean that the files in this dir can be removed and renamed only by its owner? then how can i let my team members to rename files in branch? | 19:36 |
| LeiraHua | asabil: shouldn't i set guid on this dir, that make sure all the files in this dir share the same group? | 19:37 |
| asabil | yep | 19:39 |
| LeiraHua | yep for guid? | 19:40 |
| asabil | yep | 19:40 |
| asabil | s/sticky bit/set guid/ | 19:40 |
| asabil | I always confuse the name | 19:41 |
| asabil | LeiraHua: I meant the set gid bit, not the sticky bit sorry | 19:42 |
| LeiraHua | well, i just tested this sguid, the problem is when i use "bzr init" to create a branch, the newly created branch dir has "drwxr-sr-x" permmision | 19:42 |
| LeiraHua | so only the creator can commit files | 19:43 |
| asabil | chmod -R g+w | 19:43 |
| LeiraHua | do i have to do this on server side every time manually after each time branch create? | 19:44 |
| LeiraHua | asabil: can i ask a direct question? how did you setup your repo? | 19:45 |
| LeiraHua | i just want to learn some good practice, i find it's really hard to find any complete howtos for bzr hosting~ | 19:46 |
| asabil | LeiraHua: I did it a long time ago so I don't really remember (and I have no longuer the access to those repositories) | 19:48 |
| asabil | but iirc, I had a /srv/bzr/projectX | 19:48 |
| asabil | and /srv/bzr/projectX/trunk | 19:48 |
| asabil | and /srv/bzr/projectX/branches | 19:48 |
| asabil | /srv/bzr/projectX is a repository with the set gid bit set | 19:49 |
| asabil | I created a group named projectX | 19:50 |
| asabil | and added the users to it | 19:50 |
| asabil | each user had a ~/public/bzr/projectX/ repository | 19:50 |
| asabil | that allows the users to have private branches with back ups | 19:50 |
| LeiraHua | can they submit changes into the main branch? | 19:52 |
| ubotu | New bug: #209328 in bzr-gtk ".olive.conf should be moved to $XDG_CONFIG_HOME/olive/" [Low,Confirmed] https://launchpad.net/bugs/209328 | 20:01 |
| ubotu | New bug: #209332 in bzr-gtk "Use colours to highlight different statuses" [Low,Confirmed] https://launchpad.net/bugs/209332 | 20:01 |
| hajs | Hi! On https://lists.ubuntu.com/archives/bazaar/2007q1/021660.html there was a discussion about re-editing commit messages. Is this possible now? | 20:15 |
| Pilky | hajs: from what I understand, you can uncommit something and then re-commit it with a new message | 20:16 |
| hajs | Pilky: Thanks for the hint. Unfortunately it only works with the last revision. Sometimes I find typos in changelogs and it would have been great if I could correct them. | 20:23 |
| beuno | jelmer: ping | 21:22 |
| jelmer | beuno: pong | 21:22 |
| beuno | jelmer: I'm working on the nautilus tweak you requested | 21:22 |
| beuno | do you want me to leave the global disable | 21:23 |
| beuno | or move it into a per-branch basis? | 21:23 |
| jelmer | beuno: The global disable should come for free if you add the per-branch one | 21:36 |
| jelmer | I think | 21:36 |
| beuno | jelmer: what do you mean? It has to be done differently, even on a UI level | 21:37 |
| jelmer | beuno: I mean, the option can be set in ~/.bazaar/bazaar.conf to be global and then Branch.get_config().get_user_option("disable-nautilus-bzr") should Do The Right Thing | 21:38 |
| jelmer | at a UI level the global disable could set GlobalConfig().set_user_option("disable-nautilus-bzr") and the per-branch one could call Branch.get_Config().set_user_option("disable-nautilus-bzr") | 21:39 |
| beuno | jelmer: right, I'll get to work then | 21:39 |
| beuno | thanks :( | 21:39 |
| beuno | er | 21:39 |
| beuno | :) | 21:40 |
| jelmer | :- | 21:40 |
| jelmer | ) | 21:40 |
| jelmer | (-: | 21:40 |
| beuno | /me is dizzy now | 21:40 |
| asabil | are there any plans/ideas about how to make bzr-svn faster ? | 21:41 |
| jelmer | asabil: are you running 0.4.9 ? | 21:41 |
| asabil | nop 0.4.7 | 21:42 |
| jelmer | asabil: 0.4.9 is significantly faster | 21:42 |
| jelmer | asabil: The memory leak fixes for python-subversion (present in Ubuntu hardy / Debian sid) also help | 21:42 |
| asabil | okidoki | 21:42 |
| xma | hello | 22:48 |
| xma | is aaron here ? | 22:48 |
| jelmer | his nick is abentley | 22:48 |
| jelmer | not sure if he's awake | 22:48 |
| xma | ok thank you | 22:49 |
| lifeless | hi | 22:50 |
| lifeless | abentley is probably awake at this time | 22:51 |
| xma | is he the admin of BB ? | 22:51 |
| lifeless | yup | 22:52 |
| lifeless | he runs the bzr BB | 22:52 |
| xma | k | 22:52 |
| igc | morning | 23:26 |
| bob2 | hm, the "trying to use bzr+ssh but bzr isn't in the remote path" error has become the rather scary 'bzr: ERROR: bzrlib.errors.TooManyConcurrentRequests: The medium '<bzrlib.smart.medium.SmartSSHClientMedium object at 0x896f22c>' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request.' | 23:26 |
| spiv | bob2: in bzr.dev? | 23:31 |
| bob2 | yeah | 23:31 |
| spiv | bob2: can you file a bug? That's a pretty serious regression. | 23:31 |
| bob2 | hm, gives the same error as #125784 | 23:38 |
| spiv | bob2: that bug has two different errors; the one in the original report was an interrupted connection, at least one of the comments is an errors like yours, where a smart connection could not be established. | 23:42 |
| spiv | Probably there should be two bug reports, if only because it's easier to combine bugs (via marking one as a dupe) than it is to split them. | 23:42 |
| poolie | good morning | 23:46 |
| lifeless | hi | 23:46 |
| bob2 | surreal, it only gives the scary traceback if you pass a url to 'pull' | 23:53 |
| bob2 | even if it's the parent from 'info' | 23:53 |
| thumper | is there a bzrtools update coming soon to work with bzr 1.3 in the PPA? | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!