[00:07] <vinc456> i'm trying to publish a directory that is located in /var/www/471Project. The web and sftp servers are running fine AFAIK. What is wrong with the command "bzr push --create-prefix sftp://localhost/var/www/471Project:9922"
[00:08] <jearl> I think that you need sftp://localhost:9922/var/www/471Project/
[00:09] <vinc456> that works great, thanks!
[00:10] <vinc456> i spent an hour trying to figure out what was wrong by myself, i should have asked earlier ><
[00:12] <rolly> I've put the :port in the wrong place a million times :|
[00:14] <CardinalFang> It is kinda wonky.
[00:15] <CardinalFang> Oh, wait, it's exactly right.  Always after the hostname.
[00:15]  * CardinalFang misunderstood.
[00:20] <vinc456> i guess it makes a lot of sense now that i look at it
[00:22] <Peng> Bazaar uses URIs as HTTP does, so yeah, the port goes after the hostname.
[01:34] <vinc456> i've been using my server for mostly personal use but now need
[01:34] <vinc456>       to set up a repository for classmates. i'm pushing my branch through
[01:34] <vinc456>       sftp but my sshd server only accepts public key authentication. should i
[01:34] <vinc456>       ask each group member to generate their own keys and i'll add them to
[01:34] <vinc456>       the accept list or is there a better way?
[01:34] <vinc456> sorry, about that
[01:35] <vinc456> i was thinking of generating a single key for the team. can i give repository access without shell account access or are ssh keys always associated with a user on the system?
[01:44] <Peng> vinc456: You can prevent a shell user from doing anything other than bzr.
[01:45] <Peng> vinc456: The contrib/bzr_access script might help.
[01:45] <vinc456> i'll look into it, thanks
[01:46] <keir> i just got bit by line endings... nothing like a merge conflict over the whole file! anyone working on this?
[01:49] <keir> ahah! trick is to normalize line endings of .OTHER, .THIS, and .BASE, then use meld.
[06:10] <johnny> !meta bzr
[06:10] <ubotu> Sorry, I don't know anything about meta bzr - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[06:10] <johnny> !meta dev-util/bzr
[07:02] <johnny> so, this PQM thing can only identify the committer by putting it in the description?
[07:03] <johnny> or is that just a launchpad thing?
[07:07] <johnny> aha.. ok
[07:13] <johnny> hmm..
[07:13] <johnny> i'm suprised not to see monotone mentioned at all here http://bazaar-vcs.org/BzrGpgSigning
[07:14] <johnny> they don't use gpg , but what they are doing is similiar
[07:15] <johnny> i also miss their certs :)
[07:57] <johnny> sup with rich-root-pack in bzr 1.1? i'm not sure with format i should use
[07:59] <mtaylor> johnny: you should use rich root pack
[08:00] <mtaylor> johnny: what is it about monotone that you miss... and why would you expect to see anything about it on the bazaar page on GPG signing? (just curious)
[08:01] <johnny> is there support to add arbitrary fields to revisions?
[08:01] <johnny> i didn't notice it
[08:01] <mtaylor> fields?
[08:01] <johnny> like committer
[08:01] <johnny> date
[08:01] <mtaylor> not as far as I know
[08:01] <johnny> in monotone, you can
[08:01] <johnny> they are called certs
[08:02] <johnny> i've been using it for a few years for a project i work with some other folks on
[08:02] <johnny> that's not the same as i'm trying to use bzr for
[08:02] <mtaylor> what extra fields do you normally use?
[08:02] <johnny> which is for this bookstore coffeehouse collective
[08:03] <johnny> well you have that fixes thing
[08:03] <johnny> we use X-Bug or similiar
[08:03] <mtaylor> yeah - I do that with a post-commit hook
[08:04] <johnny> you can integrate test results in them as well
[08:05] <mtaylor> mm. that's interesting
[08:05] <johnny> even branch is a cert to them
[08:05] <johnny> so branch membership of a revision is solely determined by it
[08:06] <johnny> and this metadata is signed via keys
[08:06] <mtaylor> so does monotone have a monolithic central repos then ?
[08:06] <johnny> no
[08:06] <johnny> it's dvcs
[08:06] <johnny> git took many concepts from it
[08:06] <johnny> it uses sqlite as a backing store instead of the fs
[08:06] <mtaylor> interesting choice
[08:06] <johnny> system accounts are not used
[08:07] <johnny> access is given to the db by the keys
[08:07] <johnny> that have been accepted
[08:07] <mtaylor> so if I make a local branch of code, do those keys come along so that you could interact with my branch?
[08:07] <johnny> if a rev is signed by somebody you do not trust, but is in the rev, it is pulled in, but unused
[08:07] <johnny> if you added me to the acls
[08:08] <mtaylor> weird
[08:08] <mtaylor> (not bad)
[08:08] <mtaylor> just different. :)
[08:08] <johnny> it really is amazing, everything is signed that is stored
[08:08] <johnny> period
[08:09] <johnny> it is scriptable via the lua programming language
[08:09] <mtaylor> :) we have a guy at work that puts lua in everything
[08:09] <mtaylor> I haven't quite drunk that cool-aid yet
[08:10] <mtaylor> but he really likes it alot
[08:10] <johnny> merging is completely different than the way bzr does it
[08:10] <johnny> which seems more like cvs/svn
[08:10] <johnny> with the conflict markers
[08:10] <johnny> mtn doesn't do it that way yet
[08:10] <mtaylor> what does it do?
[08:10] <johnny> you can have multiple heads of a branch existing at one time
[08:11] <johnny> so a pull doesn't have to be updated to
[08:11] <johnny> if there is a conflict, you can ignore it
[08:11] <mtaylor> um.
[08:11] <mtaylor> it still has to do something with the file, no?
[08:11] <johnny> if you choose to merge, you get an external differ
[08:11] <johnny> and you do what you gotta do, and accept hte merge or don't
[08:11] <johnny> we always merge our heads
[08:12] <johnny> but it isn't required
[08:12] <mtaylor> bk is like that
[08:12] <johnny> we also use identifers for branches like so
[08:12] <johnny> org.xaraya.core.stable
[08:12] <johnny> thus they are unique
[08:13] <johnny> like the java stuff.. altho we dont use java
[08:13] <johnny> selectors are accepted everywhere, which are like the options in other systems
[08:13] <johnny> but it's more of a generic query mechanism
[08:14] <johnny> and there is even a db execute command, so you can query the db directly via sql
[08:14] <johnny> so if the interface doesn't do what you want, you could get the info anwyays
[08:15] <mtaylor> so what brings you to look at bzr ?
[08:16] <johnny> i think bzr will be a bit friendlier to the folks who are working on this project
[08:16] <johnny> and it is faster
[08:16] <johnny> and having the support of an org like canonical behind it is very good
[08:16] <mtaylor> yeah - definitely use rich-root-packs then
[08:16] <johnny> that project i use monotone on.. is for real developers
[08:17]  * mtaylor pretends to be insulted by that :)
[08:17] <johnny> this one, is for folks who aren't really programmers by trade or at least not used to work together
[08:17] <johnny> sorry.. bad choice if words
[08:17] <johnny> i meant like hardc0re
[08:17]  * mtaylor pretends to be insulted by that :)
[08:17] <mwh> what's the mtn community like?
[08:17] <johnny> friendly
[08:17] <johnny> really smart
[08:17] <johnny> but small
[08:17] <johnny> git stole their thunder
[08:17] <mwh> i have this image that it's fairly propellor-head-ish
[08:17] <johnny> yes
[08:17] <johnny> it is
[08:17] <johnny> very smart guys
[08:18] <johnny> but i think it is worth it for the bzr community to pick up good ideas from them
[08:18] <johnny> monotone is written in C++ .. which is unhackable and will continue to be unhackable by most people i work with
[08:19] <johnny> which means we can't really modify it
[08:19] <mwh> sure, all good ideas are up for being stolen imho :)
[08:19] <johnny> of course.. those are the guys i trust writing a C++ app . but still.. :(
[08:19] <johnny> the project i want to use bzr with as i mentioned.. are mostly folks who've never used a revision control system before
[08:20] <mwh> would the way mtn works be amenable to writing a python client?
[08:20] <mwh> (just curious)
[08:20] <johnny> perhaps
[08:20] <johnny> they are still working out their internal interaces
[08:20] <johnny> interfaces*
[08:20] <johnny> they call it automate
[08:21] <mtaylor> could always wrap the c++ lib for use from python at the least
[08:21] <johnny> but it is usable with boost, so maybe you can wrap a python library around it more directly
[08:21] <mtaylor> I'm not a huge boost fan, actually
[08:21] <johnny> neither are they :)
[08:21] <johnny> they are migrating out many parts
[08:21] <johnny> since awhile
[08:21] <mtaylor> it's neat ... I'm impressed anyone extended stl to do what boost.python does
[08:22] <mtaylor> but it's completely impossible to debug
[08:22] <johnny> monotone will never have the kinda buildup like bzr has
[08:22] <johnny> with launchpad and all that
[08:22] <i386> monotine == segfaultville
[08:22] <johnny> there's one project i wanted to do with monotone that i just plain don't have time for
[08:23] <johnny> i386, really? i've never had one
[08:23] <i386> openembedded ?
[08:23] <johnny> after 3 years
[08:23] <i386> really?
[08:23] <johnny> we have more revs even than openembedded
[08:23] <i386> We must be talking about completely a different monotone vcs
[08:23] <johnny> altho not for long i'm sure
[08:23] <i386> :P
[08:23] <johnny> 30K
[08:23] <johnny> and at least 50 branches
[08:24] <johnny> hmm.. i'm not counting the language ones, since there isn't anything complicated goin on.. it's always push and pull
[08:24] <johnny> no merging or anything
[08:25] <i386> have they fixed it being slow yet?
[08:25] <johnny> slow doing what? transfer? not quite :(
[08:25] <johnny> so we still distribute the db
[08:25] <i386> yeah
[08:25] <johnny> sad that it has to be that way :(
[08:26] <i386> what is with that?
[08:26] <i386> Having a database I need to download is dumb
[08:26] <johnny> they need some protocol design help perhaps :)
[08:26] <johnny> i was toying with this idea of wrapping it up in an xmpp server
[08:26] <johnny> i just don't have time
[08:26] <i386> No. Dont!
[08:26] <i386> I love XMPP and I do love VCS
[08:26] <i386> but they don't belong together
[08:27] <johnny> i don't think it'll be any slower :)
[08:27] <i386> (that goes for email and vcs)
[08:27] <johnny> hmm.. how so?
[08:27] <johnny> email is a totally different thing
[08:27] <johnny> i'm sure it's better than their hacked up netsync protocol
[08:28] <i386> doesn't hg use email ?
[08:28] <i386> anyway
[08:28] <johnny> monotone used to use email.. with this depot thing
[08:28] <i386> downloading a huge 100mb database
[08:28] <johnny> before .14
[08:28] <i386> then installing that database
[08:29] <i386> is stupid
[08:29] <i386> especially when I just want to checkout some code to have a look at it
[08:29] <i386> by the time im thinking about downloading that database
[08:29] <i386> Ive lost interest
[08:29] <johnny> yeah.. they are working on partial pull
[08:30] <johnny> last i recall
[08:30] <johnny> haven't been paying much attention
[08:30] <johnny> been busy running the coffeeshop and helping those folks
[08:30] <johnny> and thus bzr
[08:30] <i386> yes
[08:30] <johnny> for now at least
[08:30] <johnny> transfer is always possible
[08:31] <johnny> once using one of these systems
[08:32] <johnny> that doesn't make me stop missing the way monotone works aside from that tho
[08:33] <i386> Im glad im not having to maintain it :)
[08:33] <i386> This build engineer has enough problems on his plate :)
[08:41] <Peng> johnny: Bazaar does support revision properties, but you have to add them through code, not through a command like in svn. No file properties yet.
[08:41] <Peng> johnny: Mercurial supports having multiple heads too. It was created at the same time as Git, and I think it was also partially inspired by Monotone.
[08:41]  * Peng is caught up on backlog now.
[08:41] <Peng> i386: Hg doesn't use email any differently than bzr.
[08:46] <mwh> johnny: what _do_ you miss about monotone?
[08:47] <johnny> all of that stuff i mentioned.. except the slow download time i386 mentions :)
[08:48] <bob2> is netsync any faster than bzr?
[08:49] <Peng> It can't be.
[08:50] <Peng> Some projects (Pidgin) put tarballs up with the history, because it's too slow and resource-consuming to download it through mtn.
[08:50] <Peng> Bzr isn't a speed demon at networking (yet), but it's not that bad.
[08:50] <bob2> wow
[08:51]  * Peng feels like a troll for saying that. :
[08:51] <Peng> \
[08:52] <johnny> yeah.. definitely not any faster
[08:53] <johnny> if monotone would have been faster, we might not have git
[08:58] <Peng> Even if it was faster, would anything have been fast enough for the kernel?
[08:58] <Peng> Well, BK, I guess..
[08:59] <johnny> yeah.. bk was very fast :)
[08:59] <johnny> we used that before switching to monotone
[08:59]  * johnny looks for init scripts for bzr
[09:00] <Peng> Init scripts?
[09:00] <johnny> something to start bzr serve on boot
[09:00] <Peng> Oh.
[09:00] <Peng> Usually people run it from xinetd.
[09:01] <Peng> Or, well, *usually* they use dumb http and sftp, or bzr+ssh (which requires no configuration except having bzr in ssh's PATH).
[09:01] <johnny> hmm.. i dont run anything else from there
[09:01] <johnny> i like the smart server idea
[09:02] <Peng> Well yeah.
[09:02] <Peng> It's faster. :)
[09:02] <johnny> but as none of my other programs use xinetd
[09:03] <bob2> wonder if anyone has benchmarked git vs bk
[09:03] <bob2> or is allowed to anymore
[09:03] <johnny> git is fast enough
[09:04] <Peng> bob2: Last I heard, you're not allowed to develop another VCS if you use bk. But a nondev could probably benchmark them.
[09:33] <aadis>  Peng: i suppose the license also disallows publishing benchmarks
[09:42] <Peng> aadis: If so, bleh.
[14:18] <easytiger> is there way to publish a bzr repo like with cvsweb etc?
[14:24] <dejv_ntb> hello
[14:25] <dejv_ntb> I'm trying to set up bazaar branch on ntfs-3g filesystem and I always get this message:
[14:25] <dejv_ntb> $ bzr init
[14:25] <dejv_ntb> bzr: ERROR: Transport error: [Errno 1] Operation not permitted: '/mnt/data/skola/.bzr' [Errno 1] Operation not permitted: '/mnt/data/skola/.bzr'
[14:26] <dejv_ntb> and if I try to repeat it, I'm getting this:
[14:26] <dejv_ntb> $ bzr init
[14:26] <dejv_ntb> bzr: ERROR: File exists: u'/mnt/data/skola/.bzr': [Errno 17] File exists: '/mnt/data/skola/.bzr'
[14:27] <bob2> easytiger: loggerhead does some of what cvsweb does
[14:27] <dejv_ntb> What can I do to start versioning that directory?
[14:55] <easytiger> bob2: cheers
[14:56] <easytiger> where can i find it though
[14:59] <easytiger> http://www.lag.net/loggerhead/
[16:44] <radish> Hi folks.  Anyone have any idea why trying to access a repository hosted on IIS would return the error "Not a branch"?
[16:59] <radish> Can anyone help?
[17:11] <ubotu> New bug: #178131 in trac-bzr "trac-bzr (all branches) broken with trac-0.11b1 and bzr 1.0" [Undecided,New] https://launchpad.net/bugs/178131
[17:30] <ubotu> New bug: #190725 in bzr "Bzr can't init branch on ntfs-3g filesystem" [Undecided,New] https://launchpad.net/bugs/190725
[19:47] <jelmer> abentley: Have you looked at DrProject (www.drproject.org)? It's a fork of trac
[19:48] <jelmer> abentley: never mind, looks like they are mainly focused on educational use
[19:50] <johnny> so, how is auth done for the smart server?
[19:50] <mwhudson> however ssh does it, generally
[19:51] <johnny> hmm.. back to creating system accounts ;(
[19:51] <johnny> it'd be nice to use the keys as auth directly
[19:52] <johnny> so i can say, i trust revisiosn from user@example.com
[19:53] <mwhudson> if signed, presumably?
[19:54] <mwhudson> you don't _have_ to use openssh of course, launchpad has bzr+ssh access and certainly doesn't create a system account for each launchpad user :)
[19:54] <mwhudson> but that's pretty heavyweight
[19:57] <johnny> how does that work ?
[19:57] <johnny> hmm..then again.i guess i trust all my users so far
[19:57] <dejv_ntb> does bzr's design to recover from this error:
[19:57] <dejv_ntb> https://bugs.launchpad.net/bzr/+bug/190725
[19:57] <dejv_ntb> ?
[19:57] <ubotu> Launchpad bug 190725 in bzr "Bzr can't init branch on ntfs-3g filesystem" [Undecided,New]
[19:58] <johnny> thanks mwhudson makes me feel better for the future if nothing else
[20:00] <mwhudson> johnny: it uses twisted.conch to implement a custom ssh server
[20:00] <johnny> aha...
[20:00] <johnny> twisted is neat
[20:05] <johnny> hmm.. it seems to be that bzr has too many options for init
[21:25] <mtaylor> not updating child fraction
[21:26] <mtaylor> what's that mean? ^^
[21:26] <jelmer> mtaylor: internal bug
[21:26] <mtaylor> :)
[21:26] <mtaylor> yay
[21:26] <mtaylor> jelmer: is there something I should gather or report?
[21:26] <mtaylor> it _seems_ to be working
[21:27] <jelmer> mtaylor: It's in the progress bar
[21:27] <mtaylor> ah
[22:06] <lifeless> its not even a bug
[22:06] <lifeless> is it?
[22:06] <lifeless> johnny: you don't need any options to use init, unless you want to do something out of the ordinary
[22:08] <jelmer> lifeless, oh? I thought it was a sign of bad API use
[22:08] <lifeless> I thought it was simply when the resolution was too small
[22:17] <igc> morning all
[22:25] <lifeless> hi
[22:27] <appcine> What should one install to use the bzr "smart" server? :)
[22:27] <appcine> I'm running an Ubuntu server (HTTP, svn, sftp, ssh today)
[22:28] <mwhudson> appcine: an ssh server and bazaar
[22:28] <appcine> mwhudson: Check.
[22:28] <appcine> :)
[22:28] <appcine> So .. now I can setup a central repositry with just those two components?
[22:30] <mwhudson> yes
[22:32] <appcine> Nice.
[22:32] <appcine> I'm getting the following: Generic bzr smart protocol error: Permission denied
[22:33] <appcine> When running bzr push --create-prefix bzr+ssh://user@server/~user/projects/myproject
[22:33] <lifeless> appcine: we don't support ~user yet in bzr+ssh
[22:33] <appcine> And googling on bzr errors just produce the source code :P
[22:34] <lifeless> appcine: try bzr+ssh://..../home/user/
[22:34] <lifeless> .../etc
[22:34] <appcine> Ah, ok
[22:34] <appcine> Was looking in the "Bazaar in five minutes" guide, though I could use the Launchpad example :D
[22:35] <lifeless> it has to be resolved on the server (obviously); patches gratefully considered :)
[22:36] <appcine> Ah, so I did this just to discover that my webhost doesn't have bazaar installed .. :P
[22:37] <lifeless> look for BZR_REMOTE_PATH
[22:38] <appcine> Ok, thank you :)
[22:39] <mwhudson> can you set bzr_remote_path by location in your config?
[22:39] <mwhudson> i guess i could figure this one out myself, but i'm lazy :)
[22:40] <lifeless> mwhudson: dunno $grep $code
[22:40] <appcine> I'm also getting this btw: bzr: warning: unknown encoding . Continuing with ascii encoding.
[22:41] <lifeless> that means on the far end you don't have your locale present
[22:41] <lifeless> you probably want to explicitly set LANG=C in your shell rc file
[22:41] <lifeless> (on the far end)
[22:41] <appcine> It's set to UTF-8 atm
[22:42] <appcine> Shouldn't bzr recognize that?
[22:42] <lifeless> the unix locales are not present
[22:42] <lifeless> nothing to do with bzr
[22:42] <mwhudson> it can't if the locale files are not present on the other end
[22:42] <appcine> What's the other end? :)
[22:42] <mwhudson> on the server
[22:42] <lifeless> e.g. you might have EN_AU_UTF8
[22:42] <lifeless> or however thats spelt
[22:42] <appcine> mwhudson: This is just local stuff
[22:42] <lifeless> and that requires specific country data even though it is utf8
[22:42] <mwhudson> oh
[22:42] <appcine> mwhudson: Like "bzr init" gives me the message
[22:43] <lifeless> appcine: oh, well your machine is misconfigured then in this same way :)
[22:43] <appcine> lifeless: Mac OS X, default install
[22:43] <appcine> Blame apple!
[22:44] <lifeless> hmm, I have no idea at this point :)
[22:44] <appcine> hehe
[22:44] <appcine> I'm nto too hot on the idea of changing things around since everything else works fine
[22:44] <appcine> but, what impact would it have for me that it doesn't recognize my locale?
[22:44] <lifeless> its probably something quite simple
[22:45] <lifeless> because I know it works for other bzr users without that error
[22:45] <lifeless> the impact is that non-ascii paths will give you more trouble/be unsupported for you
[22:46] <appcine> No non-ascii paths here
[22:46] <poolie> hi
[22:46] <lifeless> then it will be annoying but ok
[22:47] <lifeless> I do recommend you try to track it down
[22:47] <lifeless> there may be some diagnostics in ~/.bzr.log
[22:49] <appcine> lifeless: Nice log. Only encoding related I find is: "encoding stdout as bzrlib.user_encoding 'ascii'"
[22:49] <lifeless> right, its fallen back. I'll file a bug to add diagnostics there
[22:49] <appcine> Sweet
[22:49] <lifeless> My guess would be at a misspelt locale environment setting
[22:49] <appcine> Great tool btw. Just started using it right now, but it's very convenient.
[22:50] <appcine> While working without bzr on my server I'm trying pushing stuff to it .. like bzr push sftp://user@host/path
[22:50] <appcine> Can I just keep doing that for every commit until they install bzr?
[22:50] <lifeless> yup
[22:50] <appcine> Or is it like .. really, relly stupid ? :)
[22:50] <lifeless> sftp should perform quite well
[22:50] <appcine> Hmm
[22:51] <appcine> I'm getting an empty dir with a .bzr subdir
[22:51] <appcine> no other files followed
[22:51] <lifeless> thats correct
[22:51] <lifeless> we're pushing across updates to a database
[22:51] <lifeless> think of them as journal entries
[22:52] <appcine> And the journal entries would be .. like patches?
[22:52] <lifeless> if you had an something the size of an iso that you were changing, you wouldn't really want a 720MB upload when you changed a byte or two
[22:52] <appcine> That I can invoke use to create the source code somehow?
[22:52] <lifeless> you can get a working tree on the server by 'bzr checkout .' in the branch
[22:53] <lifeless> the push-and-update plugin will push and then ssh in and run bzr update in that location for you
[22:53] <appcine> bzr checkout . on the client computer?
[22:54] <lifeless> on the server
[22:54] <appcine> That's my problem -- I don't have bzr installed on the server :)
[22:54] <lifeless> if you want the files present on the server
[22:54] <lifeless> right
[22:54] <lifeless> but why do you want them there, is it your website ?
[22:54] <appcine> Yes
[22:55] <lifeless> so, think of the website as another client
[22:55] <appcine> I am, sort of :)
[22:55] <lifeless> its a client that wants a mirror rather than to edit, but its still a client of the system, and so it needs bzr
[22:55] <lifeless> until then I'd just rsync your website up
[22:55] <appcine> Yes, and I'll get it .. but unil then :)
[23:00] <appcine> Using export for today then :)
[23:00] <ubotu> New bug: #190801 in bzr "locale-setting error should log details to .bzr.log" [Undecided,New] https://launchpad.net/bugs/190801
[23:47] <cr3> how come there's no dapper .deb under the ppa: http://ppa.launchpad.net/bzr/ubuntu/pool/main/b/bzr/
[23:48] <mtaylor> cr3: because... um.
[23:48] <mtaylor> cr3: hell, I dunno
[23:59] <spiv> poolie: There's a trivial patch on https://bugs.edge.launchpad.net/bzr/+bug/129786 that looks like something that would be good to have in 1.2
[23:59] <ubotu> Launchpad bug 129786 in bzr ""bzr push" fails with vsftpd" [Medium,Triaged]