[00:01] <lifeless> jelmer: I'm also going to fix testrepository with trunk
[00:01] <lifeless> TagCollapsingDecorator doesn't forward testsRun
[00:01] <jelmer> I've been wondering about that one
[00:01] <jelmer> so far I've just been hand editing testsRun+=1 out
[00:03] <lifeless> oh
[00:04] <lifeless> I see
[00:04] <lifeless> jml: rev 91.5.21 in testrepository breaks with your TagCollapsingDecorator in subunit.
[00:05] <lifeless> jml: FWICT its working around 'after filtering testsRun is too small'
[00:05] <lifeless> as a bug on subunit. So I'm going to fix that there.
=== Ursinha-afk is now known as Ursinha
[00:11] <Ursinha> hello
[00:17] <lifeless> hi Ursinha
[01:00] <spiv> Morning folks.
[01:03] <lifeless> poolie: spiv: I wonder if someone from the bzr team could debug this repository problem reported on friday on LP ? (the mixxx/1.9 issue)
[01:21] <poolie> hi there spiv, lifeless
[01:21] <poolie> i think we should, too
[01:22] <poolie> spiv, could you look at it first?
[01:22] <poolie> i'm leaving tomorrow so i'm not the best choice
[01:29] <spiv> poolie: Ok
[01:30] <poolie> thanks
[01:45] <lifeless> thanks!
=== r0bby is now known as robbyoconnor
=== Ursinha is now known as Ursinha-afk
[07:08] <vila> hi all !
=== vila changed the topic of #bzr to:  Bazaar version control <http://bazaar.canonical.com> | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila
[07:10]  * fullermd waves.
[07:14] <vila> hmm, has anyone else trouble to access code.lp.net ?
[07:14] <vila> ha, went trough, finally
[07:30] <spm> vila: 1. heyo! 2. yeah, we've lost a key server, is causing pain.
[07:31] <vila> spm: 1. Hey :) 2. No worries
[07:42] <poolie> hi vila
[07:42] <poolie> how are you?
[07:44] <vila> poolie: hey, hopefully not jetlagged anymore ;)
[07:44] <poolie> good for you
[07:44] <vila> you bet ;)
[07:44] <vila> at least Valentine knows what jetlag *is* about :)
[07:45] <vila> now
[07:45] <poolie> haha
[07:45] <vila> thanks for the reviews on the config stuff to all !
[07:45] <poolie> S was the same when she first came to Europe with me
[07:45] <poolie> no problem, thanks for writing it
[07:45] <poolie> it looks really good and i'm keen to see it landed
[07:45] <poolie> i hope that came across in the reviews
[07:46] <vila> yup
[07:47] <vila> there are some points I don't fully agree and I'll explain why but there are also missing parts that made the review harder, I'll also explain the plan to go from there but may be we can discuss it briefly here
[07:47] <vila> roughly,
[07:48] <vila> I'd like to instrument the test suite so we can use it to gather useful stats for a significant set of config uses
[07:49] <vila> and from that being able to compare the actual and the proposed implementation when it comes to number of IOs and other more fine-grained patterns (how may objects are built, reused etc)
[07:49] <poolie> i'm going to be leaving sydney tomorrow and i'll be semi-offline
[07:49] <vila> s/may/many/
[07:49] <vila> ok, np
[07:49] <poolie> at UDS, until i see you after that
[07:50] <poolie> so, grab my attention if you want to talk
[07:50] <poolie> but don't block too much on me
[07:50] <vila> ok
[07:50] <poolie> maybe we should talk now about the points where we don't agree?
[07:50] <vila> your comment on the whole mp triggered a series of 'yes' from me ;)
[07:50] <vila> ha right,
[07:51] <vila> one is using ConfigStore instead of config.Store, I'd like to use this work to show case my ideas there, concretely introducing __repr__ to address your point about python tracebacks to start with
[07:51] <vila> i.e. I think there are still valuable discussions to have about name spaces
[07:54] <vila> the distinction between read-only/mutable as class names, hmm, there are various ways to look at it, I need to dig a bit more so not really a disagreement
[07:54] <poolie> i'm glad you mostly liked it
[07:55] <poolie> ah, this reminds me a bit of the thing a while ago about 'import config;. .... config.Store(...)'
[07:55] <poolie> which istr john objecting to
[07:55] <poolie> and i'm not a big fan myself either
[07:55] <vila> callables for sections: I'm only mid-way in the whole implementation and I don't want to optimize too early
[07:55] <vila> I think jam *agrees* with <module>.<symbol> instead
[07:56] <lifeless> spiv: hi
[07:57] <lifeless> spiv: did you have any luck with that bug ?
[07:57] <vila> but some sections are just dicts (true python dicts or almost true python dicts) so forcing the caller to wrap them in a callable sounds weird
[07:57] <poolie> i'm not sure exactly what you're talking about here
[07:58] <vila> I also have the intuition that not caching them may simplify building stack variations (as in, I have a config.LocationStack for '/xx/yy' and I reuse it to build one for 'xx/yy/zz')
[07:59] <vila> poolie: nm then, I'll explain better in the review
[07:59] <poolie> re your comment above
[07:59] <poolie> i'm not so sure about instrumenting the performance during the test case
[07:59] <poolie> i mean, during the test suite in general
[07:59] <poolie> its patterns are not necessarily very representative
[08:00] <poolie> a deterministic test for some particular cases could be good
[08:00] <poolie> or, i guess, measuring the overall test run time
[08:00] <vila> I'm more after numbers than time
[08:00] <poolie> but perhaps better measuring actual bzr operations like branching or merging
[08:01] <vila> i.e. reading/writing  1.000s config files vs 10s
[08:01] <vila> err 's not seconfs
[08:01] <vila> seconds :)
[08:04] <vila> and I think the test suite is still somehow representative of *somthing*, we just need to learn to use it as what it is
[08:07] <vila> it may not *directly* translates to the user experience but being able to get some numbers for one set of operations across various platforms (for example) may still be interesting
[08:08] <poolie> ok
[08:08] <poolie> were you planning to do this before merging?
[08:08] <vila> and it will help demonstrate goals like: and now we read a given config file only once per operation
[08:09] <vila> not necessarily, I haven't look precisely yet, but since the overall proposed stack doesn't interfere with the actual implementation, I'd be happy to land everything that reached an agreement and continue with incremental steps
[08:09] <spiv> lifeless: some, although I've been perturbed by intermittent segfaults in bzr while doing so!
[08:10] <lifeless> \o/
[08:10] <poolie> !
[08:10] <spiv> (current hypothesis is my hardware)
[08:10] <poolie> seems likely
[08:10] <poolie> maybe time for a memtest run?
[08:10] <spiv> Yeah.
[08:11] <fullermd> What, you just check for logged ECC events...
[08:11] <vila> fullermd: :-p
[08:11] <spiv> (Although the memtest-like that lenovo includes in Windows saw no issues a few weeks ago when I let it do a full system check)
[08:12] <lifeless> spiv: you've moved on from your dell?
[08:13] <spiv> lifeless: Yeah, since nearly a year ago now!
[08:13] <spiv> Thinkpad T410
[08:15] <poolie> spiv,  can you put a note on the bug saying what you did find out, before you end your day?
[08:15] <poolie> or maybe before you reboot into that
[08:15] <spiv> poolie: yep
[08:16] <poolie> thanks
[08:18] <poolie> wee, look at all the builds
[08:18] <poolie> vila, regarding class naming
[08:19] <poolie> at the moment we have a reasonably consistent practice of just using the class name in the repr, just importing them directly, and making them tolerably unique
[08:19] <poolie> i think if you want to change that we should probably try to do so independently of any other work
[08:20] <poolie> though it becomes a bit like those cases where you would never get around to doing the cleanup if it wasn't as part of a particular bug
[08:20] <poolie> at any rate i think having the _discussion_ separately may be better
[08:20] <poolie> it will give you a chance to explain the advantage
[08:22] <poolie> vila, can you see my direct messages?
[08:26] <jam> morning poolie
[08:26] <poolie> hi there jam
[08:27] <vila> well, I don't think we are that consistent, if only because we had a lot of cases where it broke or lead to weird behaviors with lazy imports
[08:27] <jam> vila: I do prefer "from bzrlib import config; config.XXX" however, I'm not sure about config.Store vs config.ConfigStore. The main issue is stuff like tracebacks don't print the module for objects. So you just see "Store". Thus, even though the code may have namespaces, classes should generally be unique.
[08:28] <vila> jam: hence my proposal to add the module into the __repr__ , AFAIK, we never extract them from there so if the issue is just that they are missing, adding them should fix it
[08:28] <sobersabre> hi guys.
[08:29] <sobersabre> I'm looking for an email post-commit notifier plugin.
[08:30] <vila> jam, poolie: part of the issues with lazy imports are probably linked to the fact that importing a symbol into another module *duplicates* this symbol, while using the module.symbol syntax doesn't
[08:31] <poolie> hi there
[08:31] <poolie> sobersabre, bzr-email?
[08:31] <poolie> vila i find always writing config.Store() in the code is a bit long
[08:31] <poolie> (though i guess not that much longer than ConfigStore)
[08:31] <vila> come on, no longer than ConfigStore()
[08:32] <vila> yup
[08:32] <poolie> hm
[08:32] <poolie> anyhow, i wouldn't block the review on it
[08:32] <vila> cool
[08:32] <poolie> _my_ experience with python tends to lead me to prefer fairly standalone class names
[08:32] <sobersabre> I looked at bzr-email and bzr-email-notifier
[08:33] <poolie> but i'm not sure i can objectively justify it
[08:33] <poolie> i have certainly had cases where it was quite confusing that there were two different Foos from different modules
[08:33] <sobersabre> I am not sure where I'm failing, but I need to be able to control the destination of emails on per folder basis. which of them supports this ?
[08:33] <poolie> istr one case of something like whatever.Exception
[08:34] <poolie> bzr-email will do that and i'm pretty sure the docs have examples
[08:34] <poolie> sorry i missed where you said you looked
[08:34] <poolie> perhaps it is not clear enough
[08:34] <sobersabre> poolie: I looked at the examples. I didn't see referring to location.
[08:35] <sobersabre> I somehow remember that there can be a section definition [url] and below it its own definitions for destionation, etc.
[08:35] <vila> poolie: well, in my case it's not specific to python, it's more about having a rule that fails in mysterious ways at the most inconvenient times ;)
[08:35] <poolie> basically you want a [/home/sobersabre/....whatever] section in your .bazaar/locations.conf
[08:35] <sobersabre> but I don't remember the syntax of the right url.
[08:35] <poolie> then under that, mail_to=who@example.com
[08:35] <sobersabre> OH!
[08:35] <poolie> i don't recall if that's the right variable
[08:35] <sobersabre> I think this is what I've missed locations.conf!
[08:36] <poolie> what's the rule?
[08:36] <sobersabre> poolie: no idea. I want to send to various destination depending on the location.
[08:36] <sobersabre> lemme reread the fine manual.
[08:37] <vila> importing symbols and creating duplicates. This led to believe I failed all socket/thread leaks only to realize that get_transport has been duplicated before I could redefine it was the most painful one
[08:38] <vila> but many IllegalScopeReplacer failures have the same root cause
[08:38] <vila> the trouble is that you can *most of the time* import symbols and be fine
[08:38] <poolie> ah, that can be bad too
[08:38] <sobersabre> hm... poolie I don't see any location related example in the output of bzr help email
[08:38] <vila> but suddenly one case breaks and it's generally quite hard to fix
[08:39] <poolie> ok
[08:39] <poolie> and then config.ConfigSection is a bit long
[08:39] <vila> and redundant
[08:39] <poolie> if the alternative is to dot-qualify every single symbol things will be pretty long everywhere though
[08:40] <spiv> vila: I don't like making our code a bit more verbose just to make monkey-patching globals more effective.  I'd rather fix the need to monkey-patch that object at all.
[08:40] <vila> there are valid cases where a module can relay a symbol
[08:41] <spiv> Or am I misunderstanding/remembering what you mean by "redefine"?
[08:41] <vila> spiv: true, that means adding registries here and there and I'm all in favor of doing that because it makes the code clearer anyway
[08:41] <poolie> yeah
[08:41] <vila> (get_transport is really a registry in disguise anyway)
[08:41] <spiv> vila: sometimes hooks rather than registries, but yeah.
[08:41] <vila> spiv: indeed
[08:43] <vila> as for ConfigSection, the only valid use cases should be to define daughter classes and I don't mind being a bit more verbose there
[08:44] <poolie> anyhow, i wouldn't block on it but i would prefer if you find more explicit names
[08:45] <vila> poolie: funnily enough, that's one of my goals and we seem to all agree that making the *module* name part of them is a Good Thing
[08:46] <poolie> what i mean is i would prefer 'class ConfigStack' etc
[08:46] <poolie> i'm happy to also separately look at how things interact with lazy import etc
[08:46] <vila> yeah, we disagree on the dot and the case is what I meant ;)
[08:53] <poolie> let's not get stuck on it
[08:54] <vila> indeed, if it's too controversial I'll wait for a better case anyway, my query here was: can I have a go here and see if we can reach an agreement
[08:55] <vila> if we can't, I can always rename all classes in the end before they are used in the wild
[08:59] <poolie> vila i hate to interrupt you from this but i would like you to have a look at a bug for guilhem
[08:59] <poolie> which is bug 494147
[08:59] <ubot5> Launchpad bug 494147 in FEniCS Web "The platform sniffer is highly flaky" [Undecided,New] https://launchpad.net/bugs/494147
[08:59] <poolie> hm no
[08:59] <poolie> bug 494197
[08:59] <ubot5> Launchpad bug 494197 in Bazaar "Fail to create .BASE when getting conflicts in some criss-cross merges" [High,Confirmed] https://launchpad.net/bugs/494197
[08:59] <poolie> heaven help us when we get to seven digits
[09:02] <vila> poolie: ghaa, I don't even understand what jam is saying in the last comment so that will be a huge context switch ;-/
[09:02] <poolie> hm, maybe jam could do it?
[09:02] <vila> well "understand" as in: having an idea of what code is involved there
[09:03] <poolie> so he has push of tags, and some bugs about tree references
[09:03] <poolie> the first seemed like it might need time to digest
[09:03] <poolie> maybe he'll be back in a bit
[09:03] <vila> at least pairing would minimize the effort
[09:20] <jam> I could, or I certainly could pair on it
[09:21] <jam> the depth is certainly a bit tricky, because the obvious answer doesn't work very well because of side-effects
[09:21] <poolie> there was one other he mentioned which might be easier...
[09:22] <poolie> bug 721211
[09:22] <ubot5> Launchpad bug 721211 in Bazaar "bzr merge --weave gives superfluous content conflict" [High,Confirmed] https://launchpad.net/bugs/721211
[09:30] <vila> O.M.G. When did the comments on mps became rezisable ? Hug from me to the guy fixing that ;)
[10:05] <bialix> heya vila
[10:06] <vila> bialix: heya !
[10:06] <vila> bialix: I may have some mail backlog but: did you release qbzr this week-end ?
[10:06] <bialix> so, tomorrow is 2.4b2 official day, isn't it?
[10:06] <vila> in theory, yes
[10:06] <bialix> vila: just finished it. my weekend is still going
[10:07] <bialix> 1-2 May is holiday in ex-USSR
[10:07] <vila> bialix: but the source is already frozen so it's more about announcing the installers anyway and you made it clear that using trunk were fine
[10:07] <vila> s/trunk/qbzr trunk/
[10:07] <vila> ha ha, lucky you ! Only 1st is holiday here and that was a Sunday ;)
[10:08] <bialix> well, I wonder if Gary will be able to build win32 installer
[10:09] <bialix> I need to setup my own build machine, I just need several free days for this
[10:09] <bialix> new qbzr is pretty exciting, IMO
[10:10] <bialix> I'm glad we have so many good contributions for it
[10:10] <bialix> vila: http://bazaarvcs.wordpress.com/2011/05/02/qbzr-0-21-beta1-new-features/ :-)
[10:12] <vila> bialix: cool !
[10:12] <bialix> :-)
[12:10] <jam> vila: do you have a clean run of windows since my last patch?
[12:20] <vila> jam: lunch time, but I haven't checked yet, will do and report
[12:25] <jelmer> jam: still there?
[12:27] <jelmer> jam: I'm trying to make sure I get the logic for creating new text revisions right. What I have currently:
[12:28] <jelmer> * for directories only a new text revision is created when the directory is created
[12:28] <jelmer> * for files/symlinks a new text revision is created if the text or the metadata changes or if there were multiple (different) text parents
[12:29] <jam> jelmer: not quite correct
[12:29] <jam> renames will create a new record for directories and files/symlinks
[12:29] <jam> vila: thanks, everything I saw was failed runs
[12:29] <jelmer> jam: ok
[12:30] <vila> jam: yeah, early fails to make matters worse :-/
[12:30] <jelmer> jam: and IIUC directories don't get a new text revision when their children are created
[12:30] <jelmer> jam: ?
[12:30] <jam> jelmer: so for files, if you think in terms of 'last modified'. If one sides supersedes another, than we just take it. If neither is a "head" then we create a new entry
[12:30] <jam> jelmer: directories are not updated by changing children, correct
[12:31] <jelmer> jam: when you say one side supersedes the other, you mean that if a merge takes the version from one of the parents as-is, the text revision stays the same?
[12:32] <jelmer> iow, just the text revision from that parent?
[12:32] <jam> jelmer: http://paste.ubuntu.com/602216/
[12:32] <jam> if history goes down
[12:33] <jam> if when we merge C into B
[12:33] <jam> if C says "A", and B says "B", then B supersedes A, and wins cleanly (no new text)
[12:33] <jam> if C and B say C and B, then we create a new entry for D
[12:33] <jelmer> ah, I see
[12:34] <jelmer> jam: I think I have a clear idea of it now. Thanks
[12:35] <jam> jelmer: this is the hardest one: http://paste.ubuntu.com/602220/
[12:35] <jam> at least, the hardest to get right if you don't track last-modified directly
[12:35] <jam> I'm not 100% sure it is *worth* spending a lot of time on. But it does mean graph correct vs wrong
[12:36] <jam> which is why we didn't just go with sha1 as our text handle, because wanted file graphs, and sha1 can converge
[12:36] <jam> while the graphs never do
[12:36] <jam> hg uses sha(parent_sha1 + content)
[12:36] <jam> which doesn't often converge
[12:37] <jam> unless 2 commits apply the same patch to the same base revision
[12:37] <jelmer> I'm mainly worried about getting the text store revision graph right, as not getting it right leads to bugs like bug 485601
[12:37] <ubot5> Launchpad bug 485601 in Bazaar Subversion Plugin "missing chk node(s) for id_to_entry maps" [Critical,In progress] https://launchpad.net/bugs/485601
[12:38] <jelmer> jam: are there tests for this behaviour, and if so, where do they live?
[12:38] <jam> jelmer: probably in per_commit_builder
[12:39] <jam> or per_repository test_commit_builder ?
[12:40] <jelmer> jam: That makes sense, thanks.
[12:40] <jelmer> jam: Found them.
[12:40] <jam> I count 86 tests in that file, so it is fairly complete for edge cases
[12:40] <jam> also tests kind changes (file becoming directory, etc)
[12:42] <jelmer> looks like I need to fix the testsuite to not require a working tree in the same location first :-/
[12:44] <lamont> what's the bzr equivalent of cherry-pick?
[12:44] <jam> lamont: "bzr merge -c REVNO" ?
[12:44] <lamont> or 'tever to get just a single revision in a manner that I can commit it to a different branch, with the tracking I want
[12:44] <lamont> can I do it without the branch?
[12:45] <jam> lamont: I'm not sure what you mean by "with the tracking I want". And I don't know how you merge without the branch.
[12:45] <lamont> that is, export it from one, sneakernet or whatever it to the other, and then commit it?
[12:46] <jam> lamont: "bzr send -c REVNO -o outputfile; bzr merge outputfile" I think works
[12:46] <jam> but you may need "-r REVNO-1..REVNO"
[12:46] <jam> and send gets a bit funky in general, because it is trying to be smarter than you
[12:46] <lamont> in that other system I sometimes use, I can email the patch in a manner that the far end can stuff it into their branch
[12:47] <lamont> "the tracking I want" == the commit is intact as itself, and a future merge back from the other branch won't cause a conflict simply because of being the same change
[12:47] <lamont> ok
[12:47] <jam> lamont: merges are never a conflict simply because of being the same change. It may conflict if you then do a change on top of that one
[12:47] <jam> (patch is change a => b, but you then change it to C, a future merge may conflict because of A=>B)
[12:48] <jam> lamont: I would probably say, get access to the branch if possible, as that makes life easier, but other ways are possible if necessary
[12:49] <lamont> I would think that if I make the identical change in two branches, that there could be a merge conflict, no?
[12:49] <lamont> ISTR seeing just such a thing at least once in the last decade...
[12:49] <jam> lamont: identical change == no conflict, just happy convergence
[12:49] <lamont> well, near-decade
[12:49] <jam> the main problem is near-identical changes
[12:50] <lamont> right
[12:50] <lamont> and whitespace prolly matters
[12:50] <jam> yep
[12:51] <jam> I think we could do something about whitespace, but in some languages it *really* matters.
[13:16] <vila> jam: yes, your patch fixed the issue
[13:17] <jam> vila: thanks
=== Ursinha-afk is now known as Ursinha\
=== Ursinha\ is now known as Ursinha
[15:19] <jelmer> Is python2.5 now acceptable for 2.4?
[15:19] <jelmer> I think I missed the last bit of discussion about it wrt John's patch.
[15:58] <jam> jelmer: my specific patch is bumped in favor of a compatible one. I don't think the decision is 100% clear to me yet
[16:24] <naoki> I want a preprocessor for Python....
[16:25] <naoki> #if PyVERSION < 2060
[16:25] <naoki> #define b(s) s
[16:25] <naoki> #else
[16:25] <naoki> #if PyVERSION < 3000
[16:25] <naoki> #define b(s) bs
[16:26] <naoki> #else
[16:26] <cbz_> So pipe the script through cpp at setup
[16:26] <naoki> #define b(s) s
[16:26] <naoki> #endif *2
[16:27] <naoki> If we use macros like these, we can generate source package for 2.5 and 3.0.
[16:37] <naoki> #define b(s) b##s
[16:38] <naoki> My cpp stops because b"foo" is not a valid token in C.
[16:39] <cbz_> m4 plus a set of custom macros then ;)
[17:08] <naoki> So we can prepare for moving to Python3 without stopping Python 2.5 support.
[17:08] <naoki> B("foo") => "foo" (for Python 2.5
[17:09] <naoki> B("foo") => b"foo" (for Python 2.6 and 3
=== med_out is now known as medberry
[19:05] <tbnorth> hi all - is there a way to move a file from a branch in one project to a branch in another project, i.e. move a file between projects which are both under bzr, but not really related?
[19:15] <jelmer> tbnorth: there is "bzr add --use-file-ids-from" which can let you keep the existing file id in case the projects are ever merged in the future
[19:16] <tbnorth> jelmer: so you'd lose the history in the file's new home, but get it back it the projects later merged?
[19:17] <jelmer> tbnorth: yeah. The alternative is to use "bzr merge -r0..-1 ../path/to/file". That will bring in the history of that specific file but also of the rest of the branch.
[19:18] <tbnorth> ok, thanks.
[19:21] <CoffeeIV> I have a project in which some .pdf files are being recogized as binary, and some are not. (doing a bzr diff makes it obivous which are which)  I have looked at https://bugs.launchpad.net/bzr/+bug/218128 , just wondering if there was a workaround
[19:21] <ubot5> Ubuntu bug 218128 in Bazaar "want a way to mark files as binary even if they look like text (eg pdf files)" [Medium,Confirmed]
[19:47] <morsik> hi
[19:47] <morsik> i just installed bzr on my debian server
[19:47] <morsik> friend (he have shell account) asked me for this
[19:48] <morsik> but, it's possible to add someone to his bazaar so someone can make changes in his project?
[19:48] <morsik> the only way i see is creating sysaccount for someone...
[19:50] <levu> is it possible to merge only one file?
[20:35] <morsik> why when i'm doing  bzr co bzr+ssh://username@server/ i'm getting:   bzr: ERROR: Not a branch: "bzr+ssh://username@server/".
[20:35] <morsik> ?
[20:37] <lifeless> morsik: that url is at the root of the server, generally there will be a path component as well
[20:37] <morsik> lifeless: i tried /projectname too, with the same result
[20:38] <morsik> i'm trying to do multiuser repo...
[20:45] <lifeless> morsik: have you read the docs on this?
[20:46] <morsik> lifeless: what doc? this? http://wiki.bazaar.canonical.com/BzrAccess
[20:48] <lifeless> ~http://doc.bazaar.canonical.com/bzr.2.3/en/
[20:48] <lifeless> bah
[20:48] <lifeless> morsik: http://doc.bazaar.canonical.com/bzr.2.3/en/ -
[20:48] <morsik> this is the same link ;p
[20:48] <lifeless> http://doc.bazaar.canonical.com/bzr.2.3/en/admin-guide/index.html and http://doc.bazaar.canonical.com/bzr.2.3/en/tutorials/index.html
[20:48] <lifeless> may be useful
=== zyga is now known as zyga-afk
[20:52] <morsik> lifeless: i saw this tutorial
[20:52] <morsik> i created repo on user1
[20:52] <morsik> but anotheruser needs to have access to it...
[20:53] <morsik> i created also .ssh/authorized_keys
[21:20] <jelmer> morsik: where is your repository located on the server, what's the path?
[21:29] <morsik> jelmer: /home/sirmacik/sites/bzr  and here is project /proj
[21:30] <jelmer> morsik: are you running "bzr co bzr+ssh://username@server/home/sirmacik/sites/bzr/proj" ?
[21:30] <morsik> no
[21:32] <jelmer> morsik: what are you running?
[21:32] <morsik> jelmer: ok, that syntax works...
[21:32] <jelmer> morsik: you need to specify the full path on the server; you can use ~ to mean the users home directory
[21:33] <morsik> question is, whats permissions should be on sirmacik user so i can modify his project
[21:35] <jelmer> morsik: writable in some way by your user account; you could put them in the same group and make the repository group writable
[21:36] <morsik> yeah, that i know, but probably theres no other nice option?
[21:40] <jelmer> morsik: there's also the bzr_access script
[21:40] <jelmer> http://wiki.bazaar.canonical.com/BzrAccess
[21:40] <morsik> jelmer: i tried this, with no success... or i don't know how to use it
[21:41] <jelmer> morsik: where did you get stuck?
[21:43] <morsik> jelmer: well, i created user, i write command="" into .ssh/authorized_keys on sirmacik and otheruser
[21:43] <morsik> i created bzr_access.conf
[21:43] <morsik> but hmm... i didn't create ssh keys
[21:44] <jelmer> morsik: bzr_access works by being installed in the account of just one user
[21:44] <jelmer> morsik: it lets all the users ssh into the same user account and then looks at the ssh key that was used to login to identify the user
[21:45] <morsik> mhm...
=== r0bby is now known as robbyoconnor