[00:00] <jelmer> awilkins: any chance you can file a bug with that patch attached before you go to sleep?
[00:04] <awilkins> jelmer: Hmm, this is odd ; bzr update says tree is up to date, but there's a huge diff
[00:04] <awilkins> smore like it - diff -r 877
[00:04] <jelmer> awilkins: what do you expect "bzr update" to do?
[00:05] <jelmer> it only makes sense if you have a bound branch
[00:05] <awilkins> I was expecting it to update my working tree to the latest revision in the repository
[00:05] <jelmer> it will only do that if you used "bzr co"
[00:05] <jelmer> if you used "bzr branch" to create the branch you need to use "bzr pull"
[00:06] <awilkins> No revisions to pull , my tree is at 877 but my repos is at 891 ; hence a huge diff unless I specify 877
[00:07] <jelmer> awilkins: A repository doesn't have a tip, not sure I'm following...
[00:08] <awilkins> The source in my working tree (plugin folder) is at 877 (release 0.4.7)
[00:08] <awilkins> But the repo has revisions up to 891 (HEAD)
[00:08] <awilkins> If I diff the tree, it includes reverse diffs all the way back to 877
[00:09] <awilkins> Launchpad is fubar
[00:09] <jelmer> Where do you diff against?
[00:10] <jelmer> Also, what do you mean by repo?
[00:10] <awilkins> The revisions in the .bzr folder (it's a standalone branch)
[00:11] <awilkins> bzr log -r -1.. shows revision 891
[00:11] <awilkins> But the source is at 877
[00:11] <jelmer> "bzr revno" gives 891 ?
[00:11] <awilkins> ItYes
[00:12] <awilkins> The source being at 877 was intentional, I wanted the release tag
[00:12] <jelmer> Ah, you ran "bzr update -r877" or something?
[00:12] <jelmer> or perhaps "bzr revert -r877" ?
[00:12] <awilkins> bzr pull -r 877 I think
[00:12] <awilkins> Maybe revert
[00:12] <jelmer> revert would do that
[00:13] <jelmer> if you can send in a diff against 877 that would help too
[00:19] <awilkins> jelmer: sorry, downtime, ignored my battery warning for too long.
[00:19] <awilkins> Back up again now
[00:19] <jelmer> welcome back :-)
[00:28] <awilkins> #188233
[00:29] <jelmer> thanks
[00:29]  * jelmer waits for ubotu to announce
[00:31] <awilkins> Grr, I've reverted up to 891 and now gnu patch won't apply
[00:35] <ubotu> New bug: #188233 in bzr-svn "PATCH : fix some win32 testing issues" [Undecided,New] https://launchpad.net/bugs/188233
[00:38] <awilkins> Hooray for ~1~ files
[00:47] <rolly> Hm, if I make several revisions to a branch, how can I merge those changes to a parent branch without losing the original commit messages?
[00:47] <rolly> SVK has "--verbatim --incremental"
[00:48] <jelmer> rolly: Just use "bzr merge"
[00:48] <jelmer> bzr log will then show the merged revisions indented
[00:48] <rolly> I can't, because there is a revision that must not be propagated
[00:48] <rolly> i have to specify a range
[00:48] <jelmer> rolly: that would be a cherrypick
[00:49] <jelmer> rolly: tracking cherrypicks is not supported yet
[00:49] <rolly> OK thanks
[00:49] <rolly> This puts a damper on my plans for world domination
[00:49] <rolly> :p
[00:49] <awilkins> Do the merge and reverse merge the "bad" revision?
[00:50] <awilkins> jelmer: Do you prefer bzr send output or bzr diff?
[00:50] <rolly> That would be only slightly better
[00:51] <jelmer> awilkins: bzr send please
[00:51] <rolly> I'm just going to have to refactor this code so there aren't any "special" files that can't be propagated
[00:51]  * awilkins attaches
[00:52] <awilkins> Ah, the old "special" files with the CEO's password in.
[00:52] <rolly> yep yep
[00:52] <rolly> nuclear launch codes
[00:58] <jelmer> awilkins: For "bzr send", you have to commit ifrst
[00:58] <jelmer> you now attached an empty bundle :-)
[01:00] <awilkins> I wondered why it was so short, I was really impresed :-)
[01:05]  * awilkins attaches a patch with stuff in it
[01:09] <jelmer> thansk, merged
[01:15] <mtaylor> is there a roadmap/timeframe for 1.2?
[01:25] <awilkins> https://launchpad.net/bzr/1.2/
[01:35] <mtaylor> awilkins: thanks
[01:45] <rolly> Say, what are the *.~1~ files? No mention of them in the reference guide
[02:20] <mtaylor> anybody know what this means: "not updating child fraction"
[03:15] <jelmer> mtaylor: A progress bar issue
[03:36] <Peng> rolly: "bzr revert".
[03:42] <rolly> Peng: thanks
[03:42] <rolly> (handy feature)
[05:12] <homerj> floam likes to touch himself at night
[05:12] <homerj> don't listen to him
[05:12] <floam> can bazaar automatically throw the current revision into files at some spot I wish somehow?
[05:12] <floam> god damn it
[05:25] <rolly> automatically? there are hooks you can use
[05:29] <Peng> floam: There's no built-in support for keywords like $Id$ though.
[05:29] <floam> rolly: I just meant, magically have a number pop up in some file under version control without having to call bzr revno or anything
[05:29] <floam> Peng: ok, thanks
[05:30] <rolly> Oh I misread you. Something like CVS then eh
[05:30] <Peng> floam: Yeah, currently you have to do something like execute "bzr revno" in your Makefile.
[05:32] <floam> yeah, I was doing that. It just means I need to think a bit harder, because I was hoping the number would be there when my users run a setup.py. I'll just need to keep a static file in the distribution with the number in it
[06:06] <homerj> floam, things popping up and thinking "harder" is what leads yourself to touch yourself at night
[06:07] <rolly> That's a bit of stretch
[06:08] <floam> ...
[06:26] <mtaylor> dude. I walked in on the wrong conversation
[08:10] <awilkins> rolly: ~1~ files are "revert" leftovers
[08:41] <awilkins> jelmer: I have a new trace from bzr seltest svn on win32 if you want it.
[08:42] <awilkins> Not that you have a windows box :-)
[10:18] <awilkins> jelmer: The major error now appears to be that the support for is_executable relies on the inventory, but it's being called in the read_inventory routine (in add_file_to_inv)
[11:46] <Stavros> hello
[11:46] <Stavros> i am thinking of using bzr for regular backups
[11:46] <Stavros> does it only keep the diffs of changed files, or the whole files?
[11:47] <james_w> Stavros: diffs.
[11:47] <Stavros> even for binary files?
[11:48] <james_w> Stavros: yes, but the diffs are not very efficient in that case. They can be very suboptimal in fact.
[11:48] <Stavros> ah hmm
[11:48] <Stavros> and it keeps the history locally as well, so it wouldn't be very efficient for large files, correct?
[11:49] <james_w> Stavros: you can use a local checkout that only stores the history remotely, but requires network access for operations that query history or make changes (e.g. commit)
[11:50] <Stavros> james_w: checkins query history for diffs, don't they?
[11:50] <james_w> well, the commit has to put the data on the server, so it has to have the network access.
[11:51] <Stavros> before putting the data, doesn't it have to read the old ones to see what's changed?
[11:51] <james_w> yep.
[11:52] <Stavros> that's a bit much... but i guess my current rsync setup also does it
[11:52] <Stavros> oh hmm no, rsync is per-file
[11:55] <james_w> Stavros: it knows which files have changed, do it only has to find the old versions of those ones.
[11:55] <Leonidas> hi
[11:55] <Stavros> oh aha
[11:57] <Leonidas> is there a way to create a branch "inline", that is to have multiple branches in the same directory?
[12:01] <james_w> Leonidas: no, that is not currently possible.
[12:01] <james_w> Leonidas: or do you mean use the 'git' workflow of having one tree for multiple branches and just switch the tree.
[12:02] <Leonidas> james_w: oh, thats a pity. I wanted to do a feature branch, but making it in a new directory would be a lot of work because webserver configurations would need to be changend
[12:02] <Leonidas> james_w: yaeh, I want to do something like in git - switching the branch with git checkout
[12:02] <james_w> Leonidas: ah, you can do something like that with a bit of work using checkouts and the 'switch' command.
[12:03] <james_w> you basically create two treeless branches elsewhere on the filesystem and then have a checkout in the location you want and use 'switch' to jump between the branches.
[12:03] <james_w> I think there is a 'cbranch' command in bzrtools that makes this a bit easier as well.
[12:04] <Leonidas> james_w: ah, ok. Does not look too pretty, but this sounds good.
[12:04] <Leonidas> james_w: I also found http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#reusing-a-checkout
[12:04] <Stavros> how would i go about doing local checkouts?
[12:04] <Stavros> or is that what "co" or "bind" does
[12:04] <Stavros> ?
[12:05] <james_w> Stavros: exactly. You need to use co --lightweight to have the history only stored remotely.
[12:05] <Stavros> ah, thanks
[12:06] <james_w> Stavros: you can also see the reconfigure command which might help if you have branches already.
[12:06] <Leonidas> james_w: as far as I see, cbranch is quite what I was looking for - thanks, I'll give it a try :)
[12:07] <simony> Hi, I am using the ppa apt repository, but it complains about the crypto-key. Can I add ppa's key to my apt keys? Where can I find it?
[12:08] <james_w> simony: good question. Does it complain on update or install?
[12:09] <simony> james_w, on install
[12:09] <james_w> simony: and it says it doesn't have the public key, or that they are unsigned?
[12:10] <simony> it says: Install these packages without verification [y/N]?
[12:10] <simony> (and also, before it says: WARNING: The following packages cannot be authenticated!)
[12:11] <james_w> simony: I think this is https://bugs.launchpad.net/soyuz/+bug/125103
[12:11] <ubotu> Launchpad bug 125103 in soyuz "ppa archives are not signed" [High,Confirmed]
[12:11] <james_w> simony: so I guess that there is no public key to import to solve the issue.
[12:11] <Stavros> can't you ignore crypto warnings on apt-get??
[12:11] <Stavros> minus the second question mark
[12:12] <james_w> (sorry, I haven't used PPAs, so I don't really know what the solution might be).
[12:12] <james_w> simony: #launchpad might be able to give you a better answer.
[12:12] <simony> I can ignore them, yes. Was hoping not to :-) Thanks
[12:13] <james_w> Stavros: I think there is --allow-unauthenticated, but that is just the same as typing yes, so it doesn't really solve the problem.
[12:14] <Stavros> ah
[12:31] <jelmer> re
[12:42] <jelmer> awilkins: Yeah, I would be interested in seeing that output
[12:54] <dato> jelmer: hi. when I branch with bzr and svn-psh to a svn repository, it seems to get one spurious revision. see revs 423-424, and 415 in https://forja.rediris.es/svn/csl2-minirok for an example.
[12:54] <dato> jelmer: I would've expected 424 to be 423 (that is, cp+that change already)
[13:12] <jelmer> dato: Hi
[13:12] <jelmer> dato: Please file a bug :-)
[13:12] <jelmer> This does look like a bug, indeed.
[13:47] <awilkins> jelmer: http://filebin.ca/nzoebw/bzr-svn-win32-test.zip
[13:47] <jelmer> awilkins: Thanks
[13:49] <jelmer> awilkins: The _inventory bit should be fixed in newer revisions
[13:49] <awilkins> Was just about to mention it :-)
[13:53] <jelmer> awilkins: I've just committed another revision that should help fix the executable bit
[13:53] <jelmer> awilkins: Any chance you can run selftest again on a newer revision?
[13:54] <awilkins> Sure
[13:55] <awilkins> There's a lot of "permission denied" problems cleaning up temp dirs, but not fatal
[13:55] <awilkins> And not really a bzr-svn test problem ; it's in the base test class
[13:56] <jelmer> Well, the cleanup probably fails because those files are still open by bzr-svn
[13:57] <awilkins> I see that a lot on *nix code that gets ported to win32
[13:57] <awilkins> svk has a load of gaffes like that too.
[13:57] <awilkins> I guess it's just a lot less graceful about unlinking files
[14:03] <jelmer> It's the difference between unlinking and deleting I think
[14:03] <dato> jelmer: there's another minor thing that I don't know if you've noticed, or consider it "candidate for fixing".
[14:03] <jelmer> unlinking (as happens on POSIX) allows you to remove a path while there are still people who have the file that path refers to open
[14:04] <dato> jelmer: if you give the bzr commit message with the editor instead of -m, in the svn log always appears an empty trailing line in the log, even if there wasn't any in the editor.
[14:04] <awilkins> Yeah, windows doesn't let you do that.
[14:05] <awilkins> I'm not sure which OS behaviour I like best, to be honest
[14:05] <jelmer> dato: I think it's svn that does that
[14:05] <jelmer> dato: bzr-svn doesn't add trailing whitespace
[14:06] <dato> ah, maybe svn unconditionally adds a \n
[14:06] <jelmer> awilkins: both have their advantages I guess
[14:06] <dato> jelmer: maybe you could strip one \n at the end of the message?
[14:07] <jelmer> If the \n is added unconditionally, sure.
[14:07] <jelmer> please file a bug though :-)
[14:08] <dato> ok
[14:10] <ubotu> New bug: #188353 in bzr-svn "Branching with bzr and svn-push'ing produces a spurious revision" [Undecided,New] https://launchpad.net/bugs/188353
[14:27] <awilkins> jelmer: http://filebin.ca/kqujcc/bzr-svn-win32-test2.zip
[14:32] <jelmer> thanks
[17:54] <bronger_> Is it possible to delete the parent info from a branch?
[17:59] <awilkins> Not sure what you mean.
[18:01] <bronger_> I had my project in an SVN repo.  With "bzr branch", I created a local branch.  WIth push, I created a copy of it on Launchpad.  This still has the SVN set as its parent.  Now I wonder whether I can detach it from the SVN.
[18:03] <luks> you can remove it from .bzr/branch/branch.conf, but the parent location doesn't really mean the branch is "attached" to the SVN
[18:04] <bronger_> So it doesn't do any harm?
[18:04] <luks> you mean removing it or keeping it?
[18:04] <bronger_> Keeping it.
[18:04] <luks> not at all
[18:04] <bronger_> Okay, thank you.
[19:13] <BlogueroConnor> hello, I want to publish (push) into a ftp directory, but, my username have a '@' in the username (that is typical for a shared hosting) and bzr don't  understand it.
[19:14] <dato> BlogueroConnor: try push ftp://you%40domain.com@server.com
[19:14] <BlogueroConnor> %40 is like @?
[19:14] <BlogueroConnor> encoded?
[19:14] <BlogueroConnor> will try it
[19:15] <BlogueroConnor> YES. it worked!
[19:16] <BlogueroConnor> But I think there is an error in this tutorial: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html
[19:16] <BlogueroConnor> because I tried...
[19:16] <BlogueroConnor> bzr push --create-prefix sftp://your.name@example.com/~/public_html/myproject (with my data of course)
[19:17] <BlogueroConnor> but I got:
[19:17] <BlogueroConnor> bzr: ERROR: Target directory XXX already exists, but does not have a valid .bzr directory. Supply --use-existing-dir to push there anyway.
[20:13] <jelmer> BlogueroConnor: bzr will only push a branch to a directory that doesn't exist yet or is empty
[20:14] <jelmer> BlogueroConnor: the tutorial about that bit looks ok to me
[20:30] <BlogueroConnor> jelmer, but this directory is empy. (it was, now I used the --use-existing-dir and it worked)
[20:31] <BlogueroConnor> jerlmer: I can give you an ftp account in my site for you to see.
[20:35] <BlogueroConnor> Now I understand
[20:37] <BlogueroConnor> the problem was that I was using mysite.com instead of mysite.com/branchname, because the user I was using, had direct access to mysite.com/branchname when you log in (the base directory of that user is branchname, so I dont have to specify it there).
[21:34] <bkc> I'm a longtime svn user. I used svn2bzr some months back on a repository, and now I need to merge changes from svn into my bzr working set.
[21:34] <bkc> bzr merge <svn url> doesn't work.
[21:34] <bkc> do I need to bzr branch <subversion> then merge that new branch into my existing bzr branch?
[21:47] <rolly> does bzr merge -r n..m <svn url> work?
[21:47] <jelmer> bkc: that only works with bzr-svn
[21:47] <jelmer> bkc: not with svn2bzr
[21:49] <bkc> yes, I have bzr-svn already installed. I just used svnimport to create the original bzr import
[21:50] <bkc> I guess bzr co svn doesn't support https
[21:50] <jelmer> bkc: "bzr svn-import" != svn2bzr
[21:50] <jelmer> if you used svn2bzr to create the original import, you can't use bzr-svn now
[21:51] <jelmer> bkc: bzr-svn should support https fine
[21:51] <bkc> ok, so I guess I need to diff3 by hand for every file then?
[21:51] <bkc> there have been changes in the bzr repository and the subversion one, I need to get the subversion changes into bzr
[21:52] <jelmer> You could try "rebasing" first
[21:52] <bkc> regarding bzr-svn with https, I have an https url to a subversion repository. How do I check it out using bzr?
[21:52] <bkc> I have a svn password on it, but I've already used svn info to cache the password
[21:53] <jelmer> bkc: You should be able to just use the https url
[21:53] <jelmer> bkc: If that doesn't work, please pastebin the error
[21:53] <bkc> I tried bzr branch https:// ... and I get bzr: ERROR: Invalid http response for https:/ .. tal2xslt/.bzr/branch-format: Unable to handle http code 401: Authorization Required
[21:54] <jelmer> bkc: Try prefixing the URL with "svn+"
[21:54] <bkc> svn+ .. I get SubversionException: ("Undefined tunnel scheme 'https'", 125002)
[21:54] <jelmer> bkc: Your local svn libraries aren't build with SSL support
[21:55] <jelmer> I think
[21:55] <jelmer> what version of bzr-svn are you using?
[21:55] <bkc> the subversion client, or the bzr build?
[21:55] <jelmer> it could also be caused by using a version of bzr-svn < 0.4.3
[21:56] <bkc> yeah, it's 0.4.1-1 I'm on feisty  using standard packages
[21:57] <bkc> but maybe I could svn co, then use bzr merge from the svn checkout directory?
[21:57] <jelmer> bkc: a .svn directory doesn't contain any historical data
[21:57] <jelmer> it will still have to go to the server and that will fail
[21:58] <jelmer> if it is at all possible, I would recommend upgrading to a newer version of bzr-svn
[21:58] <bkc> I'm worried about breaking bzr-tools, which I need for eclipse
[21:59] <jelmer> the bzr-eclipse plugin you mean?
[21:59] <jelmer> I thought that only depended on bzr-xmloutput plugin
[21:59] <bkc> yes, apparently the version I have calls out to bzrtools
[21:59] <bkc> maybe my plugin is old..
[21:59] <jelmer> beuno: ping
[22:07] <johnny_> hi, what is the best way to covert a cvs repository to bzr
[22:08] <johnny_> especially if you have just have checkouts :)
[22:08] <johnny_> the cvsps document seems to imply that you need server side access, since it doesn't support :ext: or :pserver:
[22:16] <Aviator> where can i find resources on embedded bzr?
[22:17]  * johnny_ has never even heard of that
[22:17] <Aviator> to quote: "If you want intelligent version control embedded into your application or content management system, Bazaar has the architecture you need."
[22:18] <johnny_> sounds like you can use it as a lib
[22:19] <Aviator> or backend
[22:24] <Peng> You can do "import bzrlib".
[22:24] <Aviator> and fiddle with it?
[22:25] <Peng> bzrlib is the entire codebase.
[22:25] <Peng> The "bzr" script is just a little bit of startup code.
[22:31] <Aviator> and then go where?
[22:31] <Aviator> theres a lot of submodules
[22:34] <johnny_> Aviator, gonna have to read the pydocs i assume
[22:38] <bob2_> Aviator: http://bazaar-vcs.org/Integrating_with_Bazaar might be a start
[22:40] <bkc> call me stupid. I have a checkout of an lp branch I host. I have committed my changes, but how do I upload the changes back to lp? lp's page still doesn't show my revs.
[22:41] <bob2> if it's a checkout, they're uploaded on commit
[22:41] <bkc> oh .. they finally shows up. I guess a commit on a checkout doesn't require a push.. just slow
[22:41] <bob2> right
[22:41] <bkc> thanks, I'm still trying to get the hang of bzr vs svn
[22:42] <bkc> jelmer: thanks for your help too.. was a good time to learn how to use kdiff3
[22:42] <bob2> "bzr log sftp://bazaar.launchpad.net/foobarbaz" will probably show them instantaneously
[22:50] <johnny_> so, is there a way to import a cvs repository without the full cvs root?
[22:53] <bob2> I think https://launchpad.net/bzr-cvsps-import works over the network
[22:54] <johnny_> this page says it doesn't support :ext: or :pserver: http://bazaar-vcs.org/CVSPSImport
[22:56] <bob2> hm, right
[23:27] <beuno> jelmer, pong
[23:30] <beuno> johnny_, bzr-eclipse doesn't depend on bzrtools at all
[23:31] <beuno> just bzr-xmloutput
[23:33] <johnny_> huh ? bz-eclipse ?
[23:33] <johnny_> why did i say anything about bzr-eclipse
[23:38] <beuno> johnny_, ahm, sorry, wrong person
[23:38]  * beuno should read backlogs more carefully
[23:48] <jelmer> beuno: why does bzr-xmloutput depend on bzrtools then?