[00:00] <cpinto> fullermd, it's not possible to push my local changes to svn if someone else committed code to the trunk
[00:00] <fullermd> If you can dig up the revid of the last change, you could probably make a diff relative to it, save it off somewhere, apply in reverse (to get back to that state), commit it, then re-apply the diff to get back to the changed state...
[00:00] <cpinto> ouch
[00:01] <cpinto> still, as i said, i committed my local changes to my local branch and when I fetched stuff from subversion it was... reverted? hence the pending merges
[00:02] <jelmer> cpinto: you can rebase before pushing
[00:02] <fullermd> Well, if I were going to work disconnected like that, I'd do it in a full branch, instead of mixing things up by doing it halfway with local commits in the checkout.
[00:02] <cpinto> yeah, I was reading about that plugin just now :-)
[00:03] <cpinto> fullermd, what do you mean?
[00:04] <fullermd> Well, when you have local commits that you 'update' into pending merges, you're basically doing the full distributed thing already, but without the cushion and tracking of having them in an explicit branch.
[00:04] <fullermd> So if you do something like that 'update' with local changes, you end up with a bunch of mixed up stuff.
[00:04] <fullermd> (should 'update' even LET you do that?  I'm not sure I'd agree with that...)
[00:06] <fullermd> The goal behind that set of commands/workflow is to try to make working central-but-disconnected as near as possible like straight-central, without introducing the bump in complexity of thinking distributed.
[00:07] <fullermd> I'm ambivalent about whether that's a succeedable goal.  Seems like something that will generally Work Just Fine, but occasionally get you twisted up worse because of the stuff it tries to hide.
[00:08] <fullermd> (I sometimes wish there was another flag like --show-ids to 'status' that would show the revids of pending merges; would make it easier to backstep in situations like that.)
[00:12] <fullermd> Of course, it's equally possible that I'm just a cranky misanthrope who should be ignored   :)
[00:12] <cpinto> damned  hardwired shell shortcut hehe
[00:12] <cpinto> anyway, i agree that update should make my changes "pending merges". but I'd like to have something to replay those merges
[00:13] <cpinto> either that or having bzr-svn merge remote changes into my local branch (which I have to commit) and after I push my stuff to the trunk not creating a revision with the stuff I originally retrieved from subversion
[00:16] <awilkins> I've been using svk for disconnected SVn work
[00:17] <awilkins> This has the secondary benefit of working well with plain SVN clients
[00:17] <awilkins> e.g. - the Eclipse SVN clients can be pointed at my SVK depot, but I can still pull / push
[00:18] <awilkins> I'm prepared to be the merging possibly isn't as good (I'm damn sure it doesn't track renames as well)
[00:20] <cpinto> awilkins, at some point i'd like to move everything onto either bzr or git. this stuff is just a minor nuisance but it's one of those minor things that build up and at some point you get tired of them
[00:21] <awilkins> cpinto: I'm most enthused by bzr so far ; I do a lot of windows development and git just isn't up to it on windows
[00:21] <cpinto> i'd say a proper workflow in bzr-svn wiki would help to avoid this stuff
[00:22] <fullermd> Wow, I can make a total mess of conflicts in a simple cases of local commits too..
[00:22]  * fullermd wanders off to create a bug report.
[00:22] <cpinto> awilkins, the reason for picking up bzr instead of git is mostly due to the fact that the old bazaar borrowed a lot from tla, which is the first dvcs i used :-)
[00:23] <cpinto> one cloud that's hanging over my head, is what will happen to bzr if canonical closes up shop
[00:23] <awilkins> Hmm, I went from Visual Sourcesafe to SVN to SVK to Monotone|git|Hg|bzr
[00:24] <awilkins> I've been trying DVCS tools because I admin a few SVN repos
[00:24] <cpinto> yeek, vss is a nightmare... ever had to recover a vss repo? :-)
[00:24] <awilkins> If canonical closes shop then people will fork bzr
[00:24] <i386> cpinto: yeah man - fuuuck
[00:24] <awilkins> cpinto: No, because you CANT recover a VSS repo
[00:24] <i386> VSS is a nightmare
[00:24] <i386> I did a VSS to Team Studio VCS conversion...
[00:25] <awilkins> The analyze tool can tell you some of the forms of damage, but it can't actually fix things
[00:25] <i386> we had to leave behind some of the version control history
[00:25] <cpinto> awilkins, not so sure of that... it seems that canonical is the single big player using bzr (well, the samba team also uses it)
[00:25] <i386> Do NOT store a 3 gb codebase in VSS
[00:25] <i386> and have 100 developers working from it...
[00:25] <awilkins> Let me fix that s/3 gb //
[00:26] <awilkins> Never use VSS for anything
[00:26] <awilkins> If VS Team VCS is even informed by the design of VSS I wouldn't touch it
[00:26] <cpinto> i386, last year I was asked to convert 3 vss repos to subversion and had to say it couldn't be done. tried everything i could remember, including using old tools to convert from vss to cvs expecting to be able to then convert cvs to svn. no dice
[00:26] <awilkins> In fact, since it's not OSS I wouldn't touch it either
[00:27] <cpinto> the MS guys we had on site said they wouldn't do it either
[00:27] <awilkins> cpinto: I've successfully converted VSS to SVN
[00:27] <i386> ha
[00:27] <i386> we had microsoft .NETs core team come to our company
[00:27] <cpinto> awilkins, really? how did you do it?
[00:28] <i386> to help us move to from 1.1 to 2.0... they told us it couldnt be done
[00:28] <awilkins> I can't recall now, it was one of the scripts on tigris.org
[00:28] <cpinto> awilkins, was it a perl tool?
[00:28] <awilkins> I think it was perl, yes
[00:28] <cpinto> awilkins: that one crashed on my repositories
[00:28] <awilkins> cvs2svn is python
[00:29] <awilkins> Ooh, they have a new one
[00:29] <awilkins> http://www.pumacode.org/projects/vss2svn
[00:29] <awilkins> pumacode ; sounds... fast and hungry
[00:30] <awilkins> And it can convert repos without installing VSS :-) that's a plus
[00:31] <cpinto> awilkins, right, that's the perl tool
[00:31] <cpinto> woops
[00:31] <awilkins> The reverse engineered thing that reads VSS repos is a new bit
[00:31] <awilkins> The version I used was somewhere around v 0.22 I think
[00:31] <cpinto> Released August 4, 2006
[00:31] <cpinto> still nothing new
[00:32] <awilkins> I used it in about 2004 I think
[00:32] <cpinto> oh well, my shrink would be glad to see i'm over it now
[00:33] <awilkins> Misery++ on the news today
[00:33] <awilkins> The north of england is flooded
[00:33] <awilkins> Heath ledger is dead
[00:34] <awilkins> The market is plumetting
[00:34] <awilkins> DOOOM!
[00:35] <awilkins> vss2svn has changes all thw way up to Nov 2007
[00:36] <awilkins> Meh "The engine of the world has been the US consumer ; now they need to save, who is going to do all the shopping?"
[00:37] <awilkins> You can just imagine the World Bank airdropping Visa cards onto the midwest
[00:54] <mtaylor> lifeless: I filed a bug about that thing earlier - #185103
[00:54] <mtaylor> about the bzr info -v producing a traceback
[00:55] <mtaylor> martin pool was starting to look in to it, but I told him you'd been working on it some already
[01:40] <ubotu> New bug: #185211 in bzr-svn "bzr commit fails on imported branch when renaming a directory with non-ASCII-name" [Undecided,New] https://launchpad.net/bugs/185211
[01:44] <bronson> Is it possible to integrate multiple svn repos using bzr?
[01:44] <bronson> I'd like to import 5 different svn repos as different subdirs in my bzr repo.
[01:44] <bronson> That way I can ensure I always have a single, consistent set of code.
[01:44] <bob2> that's fine, but they'll be no more integrated than multiple bzr branches in the same repository would be
[01:45] <bronson> Can I at least work on the branches side-by-side?
[01:45] <bronson> It isn't like I need to abandon one branch in my working copy to work on another one?
[01:46] <bob2> how do you mean "side-by-side"?  you could use "bzr switch", like you can with bzr branches.
[01:46] <bronson> I mean, I'd like to have both branches checked out simultaneously.
[01:47] <bronson> i.e. I have branch A mirrored from UpstreamSvnA, and branch B mirrored from SvnB.
[01:47] <bob2> /home/bronson/somecode/ and /home/bronson/someothercode/?
[01:47] <bronson> Yes.
[01:47] <bronson> Probably more like /home/bronson/myrepo/somecode and /home/bronson/myrepo/someothercode
[01:47] <bob2> sure, branches in the repository can be from different svn repositories
[01:47] <bob2> ah, right
[01:48] <bronson> Good to hear.
[01:48] <bronson> OK, I'll give it a shot.
[01:48] <bronson> bob2, thanks.
[01:48] <bob2> you're welcome
[02:40] <ubotu> New bug: #185224 in bzr "per-file message support into server: common config check {patch}" [Undecided,New] https://launchpad.net/bugs/185224
[03:53]  * igc lunch
[07:00] <ubotu> New bug: #185271 in bzr-gtk "empty branch causes exception for bzr viz" [Undecided,New] https://launchpad.net/bugs/185271
[07:16] <jelmer> tags eyecandy \o/
[07:16] <jelmer> http://samba.org/~jelmer/bzr/bzr-gtk-tags.png
[07:29] <mtaylor> hey all... bzr: ERROR: File exists: '/~ndb-connectors/ndb-connectors/telco-6.3/.bzr.backup': mkdir failed: unable to mkdir
[07:29] <mtaylor> oops. sorry
[07:29] <mtaylor> wrong window
[07:40] <mtaylor> HOLY CRAP. rich-root-packs is really, really fast
[08:39]  * igc dinner
[09:08] <lifeless> hi
[09:08] <lifeless> mtaylor: :)
[09:46] <ubotu> New bug: #185298 in bzr "`bzr whoami --branch joe@example.com` and lightweight checkout" [Undecided,New] https://launchpad.net/bugs/185298
[10:09] <bzlm> A horse walks into a bazaar...
[10:09] <bzlm> The bazaartender says:
[10:09] <bzlm> "Why the long face?"
[10:11] <lifeless> heh
[13:04] <ushimitsudoki> Is bzr appropriate for managing your website, as in develop on local box and push to server? If so, is there a tutorial or similar available?
[13:05] <bzlm> ushimitsudoki, bzr is appropriate as a version control system for managing your website.
[13:05] <luks> bzr will help you with versioning the website, not with pushing it to the server
[13:07] <ushimitsudoki> bzlm / luks: thank you ... i'm using bzr locally alright I think for a small project, and then read that some people were using it for their websites as well - just got curious about that (it never struck me to use version control for my website before)
[13:08] <beuno> ushimitsudoki, I work at a web development company, and we use bzr through out all our websites
[13:09] <luks> bzr is fine for versioning it, but 1) it won't push the actual website files to the server (which is probably what you want), 2) it will push the branch/repository (which is probably what you don't want)
[13:10] <beuno> ushimitsudoki, what we did to overcome the problem luks mentioned is a custom PHP script that checks for the latest files modified in the commits and lets you upload them via a web interface via sftp
[13:10] <ushimitsudoki> luks: what you are saying is matching up with what I had figured, I was just wondering if I was overlooking some options there
[13:10] <ushimitsudoki> beuno: that is a good idea - a bit beyond me right now, but I grok the concept
[13:10] <Peng> You can use the push-and-update plugin.
[13:11] <luks> Peng: you still probably don't want 'bzr branch'-able data on the server
[13:11] <beuno> ushimitsudoki, push-and-update works also, you just have to be careful not to allow access to .bzr with an .htaccess rule
[13:11] <lifeless> luks: deny access to .bzr :)
[13:11] <Peng> I use .htaccess and directory permissions to block access to it.
[13:11] <ushimitsudoki> bueno / peng: I will look into the push-and-update plugin as well, sounds close to what i need
[13:14] <Stavros> is the trac-bzr plugin good?
[13:15] <lifeless> fsvo good
[13:15] <Stavros> ?
[13:15] <lifeless> it works apparently, but there are quite severe model problems in trac for working with DVCS
[13:15] <luks> "works" is probably the right word to describe it
[13:15] <Stavros> oh
[13:15] <Stavros> lifeless: such as?
[13:15] <lifeless> such as wanting a heirarcy of changed directories above branches, for the timeline
[13:16] <Stavros> oh hmm
[13:16] <Stavros> :/
[13:16] <lifeless> but different branches don't have that innately, so you have to scan all branches and synthesis this view; which is expensive. svn by its model has this
[13:16] <Stavros> i see
[13:16] <Stavros> is there anything else i could use?
[13:16] <Stavros> or do you know if trac will be changed in the future?
[13:17] <lifeless> you can use trac-bzr
[13:18] <lifeless> I'm just explainin the issues :).
[13:18] <Stavros> it's just slower?
[13:18] <Stavros> true :)
[13:18] <lifeless> you could use cart,, though it is unmaintained now
[13:18] <lifeless> or launchpad
[13:18] <Stavros> hmm nah, i'll go with trac-bzr then
[13:18] <Stavros> it's not open source :/
[13:18] <Stavros> is it this? https://launchpad.net/trac-bzr
[13:18] <lifeless> I think so ;)
[13:19] <Stavros> good, thanks :)
[13:36] <Stavros> what does bzr ci --fixes do exactly?
[13:37] <ushimitsudoki> Alright I must reveal more ignorance: I'm trying to install the aforementioned push-and-update plugin. I created a plugin dir under ~/.bazaar and read the wiki on "How to Install a plugin", but I can't find a clear download link on the push-and-update Launchpad page. I did try "bzr branch http://...bzr-push-and-update/trunk", and I got a message that said "Branched 10 revisions", but I don't know where those files are. Please h
[13:38] <Peng> Stavros: It marks the commit as fixing a bug.
[13:38] <Stavros> Peng: regardless of the tracking system used?
[13:38] <Peng> Stavros: The tracking system has to be defined somewhere.
[13:38] <Stavros> so do i do just bzr ci --fixes 12?
[13:39] <Stavros> Peng: hmm
[13:39] <Peng> Stavros: No.
[13:39] <Peng> Stavros: E.g. "--fixes lp:12345" (with the Launchpad plugin) says it fixed bug 12345 on https://launchpad.net/ .
[13:39] <ubotu> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released] https://launchpad.net/bugs/12345
[13:39] <Peng> Yes, thank you, ubotu..
[13:39] <luks> Stavros: it just records that bug with URL XXX is fixed by this commit
[13:39] <luks> no other functionality
[13:39] <Stavros> Peng: i am using the trac plugin, which is supposed to have some integration
[13:40] <luks> I don't think there is a trac plugin that uses it
[13:40] <Stavros> so every developer should have the plugin installed?
[13:40] <Stavros> hmm
[13:40] <Stavros> maybe i misread then
[13:41] <luks> SVN has the advantage that it can run hooks on the server, so things like this are easy
[13:42] <luks> and since trac doesn't support external API for changing tickets, it's not that easy to do from the client side
[13:42] <bob2> ushimitsudoki: in a directory called "trunk" in the directory you ran "branch" in
[13:43] <Stavros> there's this: https://lists.ubuntu.com/archives/bazaar/2007q2/026518.html
[13:43] <luks> Stavros: what do you mean by 'this'?
[13:43] <luks> it just explains how to configure trac urls
[13:44] <Stavros> it mentions how to get trac integration
[13:44] <luks> no, how to map project:XXX to http://trac.project.org/ticket/XXX
[13:44] <Stavros> ah
[13:44] <luks> you still need a tool to read http://trac.project.org/ticket/XXX from bzr and update the ticket
[13:45] <Stavros> oh, i see
[13:45] <luks> and I'm not aware of such tool
[13:45] <Stavros> right
[13:45] <luks> I was considering writing it, though
[13:45] <luks> but that would mean I first have to install the xmlrpc trac plugin :)
[13:45] <ushimitsudoki> bob2: thank you!
[13:49] <lifeless> Stavros: 'bzr help bugs'
[13:50] <Stavros> oh, thanks
[13:50] <lifeless> (bzr help commit has a see-also of 'bugs')
[13:51] <Stavros> ah yes
[13:58] <bzlm> Peng, your nickname means "coin" in my native tongue.
[14:15] <Vercingetorigex> hi
[14:16] <Vercingetorigex> thI need help: there is a plug-in for Visual Studio of bazaar? Thanks
[14:25] <lifeless> Vercingetorigex: hi, there is such a plugin but I don't know how mature it is
[14:25] <lifeless> Vercingetorigex: google will probably find it
[14:26] <Vercingetorigex> thanks so much
[14:38] <lifeless> mtaylor: hi; yes packs are fast :)
[14:38] <mtaylor> lifeless: they make me happy
[14:48] <CardinalFang> ...fast for most verbs, anyway.
[15:39] <awilkins> How's barnsley?
[15:46] <lifeless> barnsley?
[16:11] <statik> why does bzr-gtk suddenly only have a single revision in trunk, when the version I have locally has over 400? http://codebrowse.launchpad.net/~bzr/bzr-gtk/trunk/changes
[16:11] <schierbeck> jelmer: ping
[16:12] <luks> statik: it has only a single file, named README, read it :)
[16:12] <lifeless> statik: http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk/.bzr/branch/last-revision
[16:13] <lifeless> meh thats nuts
[16:13] <statik> wow that is crazy
[16:13] <lifeless> jelmer: why not just rename the branch ?
[16:14] <statik> luks: I should have read that file though, thanks for the tip :) now I can get the latest code
[16:20] <dato> or put one of those bazaar reference branches, if lp would allow doing it (eg. with sftp, I guess)
[16:20] <dato> I think that'd be the best solution?
[16:28] <statik> latest bzr.dev gives me errors trying to pull from a 1.0 smartserver
[16:28] <statik> https://bugs.edge.launchpad.net/bzr/+bug/185394
[16:28] <ubotu> Launchpad bug 185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Undecided,New]
[16:28] <statik> any other info that I should supply?
[16:30] <lifeless> statik: known defect, see the list, kthxbye
[16:30] <ubotu> New bug: #185394 in bzr "Generic bzr smart protocol error: bad request '232' when connecting to bzr 1.0 smart server" [Undecided,New] https://launchpad.net/bugs/185394
[16:30] <statik> lifeless: ok, cool. I didn't find an open bug when I searched
[16:31] <lifeless> statik: yah, we kindof assume folk following trunk follow the list too ;)
[16:37]  * bzlm e inte i huset mer
[16:46] <ubotu> New bug: #185401 in bzr-svn "crash on checkout from SVN WC w/ unicode name" [Undecided,New] https://launchpad.net/bugs/185401
[17:23] <arkadini> whould somebody have an advice on how to split/refactor a file into a number of separate files with bzr?
[17:24] <LeoNerd> Just split it. bzr can't track movements of lines within files.
[17:25] <LeoNerd> If you're going to cut it into lots of small pieces, my suggestion may actually be add all the new pieces, then del the original
[17:25] <LeoNerd> That way you don't have a false "mv" which isn't really true
[17:27] <arkadini> no, just 1 into 2, 3 max but was hoping to preserve the history for all the "new" files...
[17:31] <lifeless> arkadini: planned feature, not there yet sorry
[17:31] <lifeless> LeoNerd: I don't think the mv is false; its not the whole story :)
[17:32] <LeoNerd> Hrm...
[17:32] <LeoNerd> But I'd prefer to in this case, ensure that a "merge" on the file definitely breaks and requires human intervention
[17:32] <LeoNerd> No chance of it accidentally succeeding where it woudl actually be wrong
[17:35] <arkadini> lifeless: fair enough, thanks
[19:13] <brink_> What is the recommended umask?
[19:14] <ernst> hi
[19:15] <ernst> just started with bazaar and am trying to setup a central repo on a ftp
[19:16] <ernst> I finished steps where I made a repo on my ftp and I checked out, and put the files from my project in my local repo.
[19:16] <ernst> but now I want to commit, which gives me this error: Append/Restart not permitted, try again
[19:16] <ernst> what can I do?
[19:17] <fullermd> Stab your FTP server.
[19:17] <ernst> with a knife you mean ... ?
[19:17] <ernst> I know it accepts APPE and RETR.. I tried those command with a command line ftp
[19:17] <fullermd> I like 1/2" rebar.  A knife could break...
[19:18] <ernst> hehe. lol
[19:18] <fullermd> But yeah, it's a pretty standard FTP failure mode.
[19:18] <fullermd> FTP is a flipping mess of a protocol.  Can use use something like SFTP instead?  That would be the easiest fix...
[19:18] <fullermd> Gaah.  "Can _you_ use".  Coffee.  Need coffee...
[19:19] <ernst> nope.. only thing I can use is plain FTP :(
[19:20] <fullermd> I think somebody once had it actually work with active FTP when it failed like that with passive; try using aftp://
[19:20] <fullermd> I can't imagine _why_ that would make a difference, but it may.
[19:20] <ernst> gonna try it now.
[19:21] <fullermd> Then take the knife to your server admin for not having sftp   :p
[19:21] <ernst> well. I can have sftp .. but it will cost me :(..
[19:22] <fullermd> What bzr version/repo format are you using?
[19:24] <ernst> I have version 1.0 and followed this steps: http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#publishing-a-branch
[19:24] <fullermd> 'k, so you'd be using packs.  I wondered if maybe they might not need append, but I guess it translates to that down the stack anyway.
[19:25] <ernst> I see..
[19:26] <ernst> well I started again and am now using aftp:// instead of ftp://
[19:27] <fullermd> lifeless: ^^^  _Should_ packs be able to do without transport-layer append, and so be more FTP-friendly?
[19:27] <ernst> first time though, using something like VCN
[19:27] <brink_> Should the umask be 002?
[19:28] <fullermd> brink_: I s'pose that depends on whether you want the umask to be 002   ;)
[19:28] <brink_> It seems we get a lot of problems with permissions after changes are pushed.
[19:28] <fullermd> The umask may affect perms when you 'bzr init'; in normal operation though, bzr bases off the existing perms in the .bzr/ dir.  It may affect working-tree files that are created, I'm not sure.
[19:29] <brink_> We're getting a bit of a mutiny that wants to go back to subversion.  I want to prevent that.
[19:29] <fullermd> Mmm.  Pushing via SFTP, and getting perm problems on directories?
[19:29] <brink_> Yes.
[19:29] <brink_> I have to fix it with chmod every once and a while.
[19:29] <fullermd> OpenSSH's SFTP server doesn't allow setting setgid.
[19:29] <fullermd> It silently strips the bits.
[19:29] <brink_> Sounds evil.
[19:30] <fullermd> If you can use bzr+ssh instead, that'll work.  And probably be faster.
[19:30] <ernst> well.. aftp:// still didn't do the trick
[19:30] <fullermd> You could cron a find .bzr/ -type d -print | xargs chmod g+s with some regularity and stave it off.
[19:30] <brink_> Does bzr+ssh work well for branching too now?
[19:31] <brink_> I suppose I could, but I don't want any flakyness.
[19:31] <fullermd> It should, yeah.  There's a few quirks with branch format default and such, but it should work just fine.
[19:31] <fullermd> I don't think I've used sftp since 0.13 or so, I moved everything to bzr+ssh
[19:31] <brink_> I was wondering if the umask was one of the issues.
[19:31] <ernst> do you have another tip  I can try fullermd??
[19:32] <brink_> I've been using bzr+ssh except for branching, the sftp seems to be much faster.
[19:32] <fullermd> Nah, that's the SFTP server "helping" you.
[19:32] <fullermd> ernst: Not really, sorry   :(
[19:32] <ernst> darn.. I wanted to use Bazaar since it works with plain ftp
[19:32] <ernst> *should work* :)
[19:32] <fullermd> ernst: It comes up with some regularity; some FTP servers just don't get along well.  There's no formal spec for attributes to support or ways of passing errors, so the FTP code is pretty DWIM-y.
[19:33] <fullermd> brink_: Mmm.  Maybe you're using a shared repo, with a lot of unrelated projects/branches in it?
[19:33] <brink_> No.  It's not a shared repo.
[19:33] <fullermd> brink_: The smart server might still be doing its "send initial branch as a tarball of the repo" thing, which could end up sending a lot more data...
[19:34] <ernst> btw.. I see that bzr makes the initial file on my ftpserver.. it just won't append to it
[19:34] <fullermd> ernst: Do you know what software the server is running?
[19:34] <ernst> how do I find ou?
[19:34] <ernst> out
[19:35] <fullermd> It may give a banner you can see from a FTP client.
[19:35] <brink_> I've notice a few postings about permission problems on Linux, but not enough detail to figure out what the solution is.
[19:35] <ernst> never mind.. found it -> it's ProFTPD 1.2.10
[19:35] <fullermd> brink_: Most of them, AFAIK, end up being the "SFTP server stripping setgid" thing.
[19:35] <brink_> Can I get away with a umask of 022?
[19:36] <fullermd> Not really.  SysV filesystem semantics need the setgid on the dir to inherit the group ownership to the files under it.
[19:36] <fullermd> You could put BSD on the server   ;>
[19:36] <brink_> So what do most people do.   Set the umask to 002?
[19:37] <brink_> Actually, the main server we're using is OS X.   So it's sort of BSD.
[19:37] <brink_> We use Linux too though.
[19:37] <ndim> POSIX ACLs could work around...
[19:37] <fullermd> Hm.  I'm not sure what set of FS semantics OS X uses...
[19:37] <ndim> ...potentially.
[19:37] <brink_> I've heard ACLs could help.   I don't know how to set them up though.
[19:37] <fullermd> I don't think bzr follows the umask for repo files; it bases it off the perms of the existing files/dirs.
[19:38] <ndim> POSIX ACLs at least have an equivalent to setgid - but without needing the g+s bit.
[19:38] <fullermd> Yeah, but that probably wouldn't invoke the FS side effect of g+s.
[19:38] <brink_> I've tried setting the sticky bit.  It doesn't seem to help.
[19:38] <fullermd> Yeah, sticky wouldn't help at all.  Might hurt.
[19:39] <brink_> Is that so?  How come?
[19:39] <fullermd> Because the semantics of the sticky bit on a directory is to not allow you to delete files you don't own, regardless of whether you have +w on the dir.
[19:39] <fullermd> (hence its use on /tmp and the like)
[19:40] <brink_> Even if you're a member of the group?
[19:40] <fullermd> Group isn't relevant there.  It's all perms.
[19:41] <brink_> So what's the proper way to setup the perms?
[19:41] <fullermd> To delete a file, you need +w on the directory it's in.  Whether you get that via user, group, or other perms, doesn't matter.
[19:41] <fullermd> Well, the proper way with SysV fs semantics is g+s, so files inherit group   :)
[19:42] <brink_> Something like this?  chmod -R 2770 repo/
[19:42] <fullermd> It's just that the sftp-server doesn't get along with that.
[19:42] <fullermd> Yah.
[19:43] <brink_> And this?   chown -R  root:repogroup repo/
[19:43] <ernst> fullermd: are there any workflows with bzr that doesn't require a correct implementation of APP? ie . it only STOREs files?
[19:44] <fullermd> ernst: I don't know; I don't know the code at that level.  I presume the transport level is translating stuff to appends.
[19:44]  * fullermd nods at brink_.
[19:45] <ernst> I see..
[19:45] <fullermd> brink_: Then periodically g+s'ing directories (not files) would clean up the damage the sftp server does.
[19:45] <fullermd> brink_: But really, bzr+ssh _is_ the better answer.  If it's significantly slower, that's probably a bug.  If you can come up with some numbers on specific cases, you should probably post it to the list so we can see what we can do.
[19:46] <brink_> You believe it's only sftp that causes the damage.  Never bzr+ssh?
[19:46] <fullermd> Yeah.  It's a specific problem; sftp-server strips the g+s bit when we ask for it.
[19:47] <fullermd> bzr+ssh doesn't go through the sftp server; it runs a local 'bzr' invocation which talks to the filesystem.
[19:47] <brink_> It's possible that bzr+ssh is fast for branching now.  I haven't tried branching with bzr+ssh in some time.
[19:47] <brink_> Maybe sftp support should be disabled?
[19:48] <LeoNerd> bzr+ssh is a lot faster than sftp, in my experience
[19:48] <brink_> For pushes & pulls it's faster.   Not sure it is for branching.
[19:48] <fullermd> Actually, sftp may work OK for packs; I don't think pack repos end up creating directories very often.
[19:49] <fullermd> knit repos will until it finishes filling out the hash bucket dirs.
[19:49] <fullermd> Maybe lock dirs still suffer from it; I don't know.
[19:49] <brink_> How do I tell if I'm using packs or knits?
[19:49] <fullermd> 'bzr info'
[19:49] <brink_> Yes.  We've had lock dir issues.
[19:50] <fullermd> But really, I wish we _did_ de-emphasize sftp more.  If there are perf bugs in the SS, they should be fixed, and sftp should be a "if you can't run bzr on the server, you can still use sftp", not a default choice.
[19:51] <brink_> I'm knit format.  Is that old?  Can I upgrade it?
[19:51] <fullermd> Packs came in with 0.92, and became default in 1.0.
[19:51] <fullermd> So if you've got people using older versions, you'll need to stay with knits.  If everyone's keeping up, and is on 1.0 or 1.1, you could upgrade.
[19:52] <brink_> If I upgrade will they fail gracefully?
[19:52] <fullermd> Well, they'll fail by saying "WTF is this?  I don't know how to work with this."  That's sorta graceful.
[19:53] <brink_> That's good enough.
[19:54] <fullermd> Packs may end up slower on sftp, if you have a large history and slow connections, since they'll have to shuffle a lot of data around for repackings.
[19:54] <fullermd> I think the SS protocols already do all that server-side.
[19:55] <ubotu> New bug: #185458 in bzr "can't add files with certain unicode characters" [Undecided,New] https://launchpad.net/bugs/185458
[19:55] <ernst> @fullermd: just using bzr branche with ftp doesn't work. still APPEND errors. Time to use a USB stick instead :( or pay anothe 2 euro 50 for sftp support.
[19:55] <Peng> I have to use sftp on one large repo because the server's process Nazi always kills smart server repacks. :P :(
[19:56] <Peng> ernst: Or find a decent host? Not that that's easy.
[19:56] <fullermd> See?  Just proves my point that there's no problem that can't be solved by finding the right person, and beating the crap out of them   :]
[19:57] <ernst> yeah that's true Peng.. only prob is, I'm happy with my host when it comes to just php + mysql + http hosting
[19:57] <fullermd> So all we need is PHP bindings for bzrlib so we can write a PHP smartserver...
[19:57] <ernst> lol :)
[19:58] <brink_> My os x bazaar thinks it's version 0.18.   Is the macports version behind?
[19:59] <Peng> Well, it is behind.
[20:00] <Peng> 0.18 isn't ancient. It goes 0.18, 0.90, 0.91, 0.92, 1.0, 1.1.
[20:01] <brink_> I see that the 1.0 dmg say's it's for leopard.  I have tiger.   1.1 seems to be for tiger, but it's experimental.
[20:01] <brink_> Not sure what fink will get me.
[20:01] <brink_> Looks like fink is 0.18-1
[20:02] <brink_> Maybe I'll try the leopard one and cross my fingers.
[20:02] <fullermd> 1.1 should be fine.
[20:03] <ernst> how do I add the pgp key from the bazaar gutsy repo?
[20:04] <ernst> I'm using ubuntu gutsy
[20:08] <Peng> It says how on the website.
[20:10] <ernst> tnx. I was looking at the wrong places..
[20:12] <ernst> mm tobad . no version 1.1 out yet for ubuntu as .deb
[20:13] <mtaylor> there's the ones in the ppa
[20:13] <mtaylor> deb http://ppa.launchpad.net/bzr/ubuntu gutsy main
[20:13] <mtaylor> deb-src http://ppa.launchpad.net/bzr/ubuntu gutsy main
[20:14] <mtaylor> ernst: ^^
[20:16] <ernst> thanx mtaylor .. that works :)
[20:16] <mtaylor> great!
[20:17]  * mtaylor really wishes that bzrtools, bzr-svn and bzr-gtk would be considered "core" plugins and released to that ppa when bzr is released
[20:17] <mtaylor> but that's just me
[20:18] <abentley> mtaylor: bzrtools is on ppa.
[20:19] <mtaylor> abentley:   bzrtools: Depends: bzr (< 1.1~) but 1.1-1~bazaar1~gutsy1 is to be installed.
[20:19] <mtaylor>   bzr-svn: Depends: bzr (< 1.0.1~) but 1.1-1~bazaar1~gutsy1 is to be installed.
[20:19] <abentley> Yeah.  It's borken, but it's there.
[20:19] <mtaylor> well yes. :)
[20:20] <mtaylor> I meant more of a process thing rather than a physical need thing.
[20:20] <abentley> Bzrtools 1.1 is on ppa, but the dependencies are messed up.
[20:20] <mtaylor> oh, fun
[20:20] <abentley> So that it wants bzr 1.0
[20:23] <ernst> fullermd, I was saying I'm getting those Append / Restart errors with bzr.. well. filezilla ftp client can 't append either. I'm gonna contact my host.. this is nonsens
[20:24] <fullermd> Nonsense?!  This is FTP!   ;p
[20:24] <ernst> hehe. well my first guess is that they disabled resume
[20:24] <fullermd> No, I think ProFTP is one of the ones that that issue is standard on.
[20:25] <fullermd> I'm flabbergasted that they want to charge more for sftp, though.
[20:25] <fullermd> After all the time I spent screwing with firewalls to try and get FTP working right, and all the gaping holes I had to open, I'd be thrilled to tears if NOBODY ever wanted to use it again and I could yank all that crap.
[20:26] <ernst> yeah I couldn't agree more.. silly thing is though, they are saying that SSH has more risks. go figure
[20:32] <Peng> But you can get those risks if you want to pay more?
[20:32] <ernst> yeah..
[20:32] <Peng> fullermd: What do you like for file servers? Just HTTP?
[20:32] <ernst> but 2 euro 50 for SSH and SFTP is too much in my opinion
[20:32] <fullermd> Well, I use NFS for file servers   ;)
[20:33] <fullermd> But yeah, file distribution, I just use HTTP.  It's simple, it's ubiquitous...
[20:33] <Peng> Har har. Ok.
[20:33] <Peng> (Isn't NFS evil?)
[20:33] <fullermd> Absolutely.
[20:33] <ernst> and everyone can get to http :)
[20:34] <fullermd> But I use it in sufficiently controlled situations that the evil is suppressed.
[20:35] <ernst> well, thanks for all the help. I'm gonna await an answer from my host
[21:15] <awmcclain> Hi all... Is the only way to get the current revision number of a file to slice up the output from bzr log FILENAME?
[21:27] <jelmer> mtaylor: I've just uploaded bzr-svn to ppa
[21:27] <mtaylor> jelmer: you are my hero
[21:27] <jelmer> I hope to also upload to ppa from now on when I do releases
[21:28] <jelmer> james_w: Is there some easier way to build for ppa than running "bzr builddeb --source --builder="dpkg-buildpackage -rfakeroot -S -sa" ?
[21:51] <mtaylor> jelmer: I just do bzr bd -S
[21:52] <mtaylor> and then I have in ~/.bazaar/builddeb.conf
[21:52] <mtaylor> [BUILDDEB]
[21:52] <mtaylor> builder = debuild
[21:52] <mtaylor> source-builder = debuild -S
[21:52] <mtaylor> quick-builder = sudo debian/rules binary
[21:52] <mtaylor> orig-dir = ..
[21:52] <mtaylor> and that works for me for ppa
[22:02] <RainCT> Hey
[22:02] <RainCT> what was the command to remove a lock?
[22:02] <jelmer> bzr break-lock
[22:03] <CardinalFang> Tee hee.
[22:05] <RainCT> jelmer: thanks :)
[22:27] <lamont> will bzr let me say 'bzr log - but only for commits that include changes to $FILE'?
[22:27] <Peng> "bzr log file"?
[22:28] <lamont> bzr: ERROR: extra argument to command log: <file>
[22:28] <lamont> win
[22:28] <lamont> otoh, if I only give it one file, it does better
[22:28] <dato> right, only one file allowed
[22:29] <Peng> Seriously? That sucks.
[22:29] <dato> yet another bit of insight brought to you by Peng
[22:30] <Peng> Also, the RIAA are jerks.
[22:30] <fullermd> Hey!  I'm _sure_ I said it first!
[22:43] <igc> morning
[23:11] <mtaylor> abentley: so any chance of someone re-uploading bzrtools to ppa as a !bazaar2-gutsy1 release with the depends fixed?
[23:11] <mtaylor> and by ! I meant ~
[23:12] <abentley> poolie does that, and he'll be here a bit later.
[23:12] <Peng> Isn't the point of PPA that multiple people have access to it?
[23:17] <poolie> mtaylor, got it
[23:17] <poolie> Peng, yes, anyone could do it, but i probably know more about it than aaron
[23:17] <mtaylor> poolie: rock.
[23:21] <poolie> abentley, i'm off the phone, i'll be there about 11
[23:29] <Peng> Nice, "apt-get update" ran at 743 bytes/sec.