[00:15] <ubotu> New bug: #182159 in bzr-git "Doesn't provide git working tree access" [Wishlist,Triaged] https://launchpad.net/bugs/182159
[02:30] <gryc> is there any way to work around a 4 hour initial `bzr push` where the .bzr directory is about 15mb?
[02:34] <jelmer> gryc: what format and transport are you using?
[02:35] <gryc> I'm using bzr+ssh, with version 1.0 I believe
[02:48] <jelmer> gryc: what format in 1.0 though?
[02:48] <jelmer> packs or dirstate?
[02:48] <jelmer> packs should probably be faster
[02:48] <gryc> I have no idea, how do I check?
[02:49] <gryc> argh, nevermind, I think it was my network's upload getting sucked dry >_<;
[02:51] <gryc> but, along those lines, is there any chance of getting a transfer speed counter added onto the end of that ascii progress bar, or is that impractical?
[02:53] <jelmer> I think there were plans for that
[02:53] <jelmer> you can check the current format by running "bzr info"
[02:54] <gryc> ah, "dirstate" then
[02:55] <gryc> sorry to bug you, it was another machine on my network eating all my upload bandwidth...the push took 9 minutes after I yanked the offending machine
[02:55] <jelmer> no worries
[02:55] <jelmer> this is another good reason we need that improved progress indicator...
[03:03] <lifeless> gryc: if all your bzr clients are 1.0 or newer, you can improve performance by doing 'bzr upgrade'
[03:05] <gryc> lifeless: thanks, I'll check with the rest of the team on that :D
[03:09] <sechastain> I have a question about tags
[03:09] <sechastain> I see that I can create them and that I can diff in reference to them
[03:09] <sechastain> but how do I branch from them?
[03:09] <sechastain> and how do I check the tags in a remote repository and/or branch?
[03:20] <sechastai2> ... no takers?
[03:46] <ubotu> New bug: #182192 in bzr "While pushing, progress bar has no upload speed indicator" [Undecided,New] https://launchpad.net/bugs/182192
[03:51] <lifeless> sechastain: I would guess at bzr tags URL
[03:52] <lifeless> and use -r tag: to access them
[03:57] <sechastain> yeah, I've been looking the past hour or so through at the code
[03:57] <sechastain> there's a secret undocumented flag --directory
[03:57] <sechastain> bzr tags --directory branch
[03:58] <sechastain> any reason why we can't dump the --directory flag?
[03:58] <lifeless> dunno
[03:58] <lifeless> not a part of the code I've looked at
[03:58] <sechastain> it's in builtins.py
[03:59] <lifeless> however its not secret
[03:59] <lifeless> bzr help tags lists it,
[03:59] <sechastain> ?
[03:59] <sechastain> man
[03:59] <sechastain> crazy
[03:59] <sechastain> I've read through that like 5 times
[07:57] <IllX> in reading about bzrweb I the comment "Recently it was updated to support the Bazaar 0.15 API"
[07:58] <IllX> being very new to bazaar I'm interested in what the 0.15 API is, but can't find a good starting point
[07:58] <IllX> surely it must be the bzrlib core
[08:00] <IllX> how do I know 0.15 is the current?
[08:04] <IllX> ah, now that I've found the api docs I see .version
[08:04] <IllX> :)
[08:45] <fullermd> Well, presumably, the API from the 0.15 release   :p
[08:49] <IllX> really
[08:50] <IllX> the way I was reading it, it gave me the impression the API might run a different version than application
[08:50] <IllX> I haven't yet got to calling .version so I wasn't sure
[08:50] <IllX> that's a long way back from 1.0
[08:51] <fullermd> Yeah.  The API's always shuffling in little bits and pieces, but most programs can usually go a number of versions one way or the other before hitting something that throws 'em.
[08:52] <IllX> yeah
[09:57] <acuster> jelmer, around?
[11:40] <ubotu> New bug: #182258 in bzr "-r before:date:xxx produce error if branch don't have revisions after specified date" [Undecided,New] https://launchpad.net/bugs/182258
[11:53] <dato> what is a mesh-merge?
[11:54] <dato> (I'm getting no google love for this)
[11:54] <fullermd> In what context?
[11:55] <dato> it's in the "[MERGE/RFC] Merge prefers to use submit branch" thread:
[11:55] <dato> > They might develop only *on*
[11:55] <dato> > trunk, or in more of a mesh.
[11:55] <dato> If they're doing mesh merging, they'll need to specify the merge
[11:55] <dato> location every time anyhow.
[11:56] <fullermd> Oh, working in some sort of full-mesh topology, where you're merging from arbitrary other people in no particular pattern, instead of working in a more star-ish setup.
[12:09] <jelmer> acuster, hi
[12:11] <acuster> hey jelmer
[12:12] <acuster> We're working on geospatial data and thinking about versionning theory. Any chance you have a list of references
[12:12] <acuster> something we could get started with? We have peculiar problems not faced by text code files but in general
[12:13] <acuster> we will face the same core issues.
[12:19] <AfC> acuster: as ever in IT, there's lots of theory, and then there's what's actually implemented. There is often a wide gulf between them, with implementation not infrequently outstripping or obsoleting "theory"
[12:20] <AfC> acuster: as applied here, I'd have to guess that your best bet would be finding a tool that actually encapsulates the concepts you want and think about whether or not you could adapt the core differencing engine to your data form (as oppose to the current bias about deltas between revisions of text files)
[12:21] <AfC> acuster: ... but that's got to be a fairly restrained (and in the case of bzr, reasonably well isolated) aspect of the tool
[12:22] <AfC> Failing all that, I'd have a word with the people doing version control on video. That's a fairly well developed area, but most of it is proprietary and/or in-house.
[12:22] <AfC> [where video == the footage for a movie on up to the video archive of CNN]
[12:28] <jelmer> acuster: I don't have any references, sorry. All I know about versioning theory is from reading the source code of the various free vcs
[12:39] <acuster> thanks both
[12:40] <acuster> AfC: we actually use a lot of theory, a la Knuth, Computational Geometry, and numeric algorithms. I was hoping there was a body of knowledge developed so I didn't have to start from scratch on this area as well
[12:41] <acuster> so far to go before getting back to real science...
[14:37] <brilliantnut> hi.
[14:37] <brilliantnut> I was waiting for Bazaar 1.1, which the calendar said would be out on the 11th..
[14:37] <brilliantnut> does anyone have any input on what happened?
[14:38] <jelmer> not sure, haven't read anything about it recently
[14:38] <jelmer> the release manager for 1.1 would be the best person to talk to
[14:38] <jelmer> I'm not sure who it is though :-/
[14:45] <brilliantnut> The google calendar entry was created by Martin Pool,
[14:45] <brilliantnut> any idea what his irc nick is?
[14:45] <jelmer> his IRC nick is "poolie"
[14:59] <brilliantnut> jelmer: would you also happen to know what timezone 'poolie' is in? as in appropriate hours to find him online?
[14:59] <jelmer> I expect he'll be online again in about 30 hours, maybe earlier
[14:59] <jelmer> he's in Sydney
[15:01] <brilliantnut> cool, thanks for the help, jelmer.
[15:01] <brilliantnut> c ya
[16:14] <RainCT> Hi
[16:15] <RainCT> Does the version of bzr in Gutsy support tags?
[16:18] <dato> RainCT: yes
[16:18] <dato> RainCT: but you have to pass --dirstate-tag to `bzr init` for it to work
[16:18] <dato> RainCT: or for existing branches, `bzr upgrade --dirstate-tags`
[16:19] <RainCT> Yes I just did that, but I wasn't sure if it would break the branch for the other developers (I'm using the latest bzr from Hardy). Thanks
[16:19] <RainCT> is there any reason why it is disabled by default?
[16:20] <dato> when a new format gets introduced, we normally wait a few releases before making it the default
[16:20] <dato> so, for example, dirstate-tags was made the default in 0.91
[16:22] <RainCT> ah :)
[16:23] <RainCT> so now if I commit & push it will also upgrade the copy in Launchpad, or what do I have to do?
[16:23] <dato> you have to
[16:23] <dato> bzr upgrade sftp:// ...
[16:23] <dato> upgrade --dirstate-tags
[16:24] <dato> if you just upgrade with hardy's bzr, it'll upgrade to a version not supported by < 0.92
[16:24] <RainCT> I did a   bzr upgrade --dirstate-tags
[16:25] <dato> very well. now that for launchpad as well.
[16:26] <RainCT> bzr upgrade bzr+ssh://rainct@bazaar.launchpad.net/%7Efreevial/freevial/trunk/ --dirstate-tags    ?
[16:26] <dato> try that, but I think upgrade over bzr+ssh does not work (didn't use to), so if it gives you an error, use sftp instead
[16:28] <RainCT> okay. the copies that the other developers have will be updated when they pull then?
[16:29] <dato> they will have to run upgrade themselves first
[16:30] <dato> pull will tell them
[16:30] <dato> bzr: ERROR: Tags not supported by BzrBranch5('file:///tmp/b/x/foo/'); you may be able to use bzr upgrade --dirstate-tags.
[16:33] <RainCT> ok. thanks for your help!
[16:34] <dato> you're welcome
[17:05] <RainCT> dato: uh.. is it normal for LP to be still updating after half an hour?
[17:05] <dato> sadly, yes... depending on the size of your branch
[17:22] <RainCT> is there some way to see how much longer it will take, or abort it?
[17:23] <jelmer> neither I think
[17:46] <Lo-lan-do> Hmm.  graph-ancestry isn't as good as bzr-viz :-/
[17:46] <Lo-lan-do> http://www.placard.fr.eu.org/~roland/tmp/superpatch.png
[17:46] <radix> wow, yeah.
[17:47] <radix> well then, hooray for bzr viz? :)
[17:48] <jelmer> blame graphviz (-:
[17:48] <Lo-lan-do> Compare to http://www.placard.fr.eu.org/~roland/tmp/Capture.png :-)
[19:34] <brilliantnut> ?help
[19:36] <Peng> What's up?
[19:38] <RainCT> dato: LP is still updating..... shouldn't this rather be a bug? :P
[19:43] <Lo-lan-do> jelmer: Is it possible to follow several SVN branches with bzr-svn?
[19:45] <Lo-lan-do> http://pastebin.com/d2876a514
[19:46] <Lo-lan-do> Seems that the history isn't preserved across branching :-/
[19:48] <Lo-lan-do> Hm.  Only the ones created through "bzr svn-push", apparently.
[19:49] <jelmer> Lo-lan-do: not sure I understand the question
[19:49] <jelmer> two non-bzr revisions in Subversion with the same changes don't have the same identity
[19:50] <Lo-lan-do> In my pastebin, I branched (using svn) trunk to branch1, then I started using bzr on them both, but they seem unrelated bzr-wise.
[19:51] <jelmer> hmm, that seems wrong
[19:51] <jelmer> can you paste the output of svn log -v ?
[19:53] <Lo-lan-do> http://pastebin.com/d34a6b6c8
[19:54] <jelmer> yeah, that's definitely a bug
[19:54] <jelmer> please file one. I think it's specific to "bzr missing"
[19:54] <Lo-lan-do> So it's supposed to work?
[19:54] <jelmer> yes, it's supposed to show you:
[19:54] <jelmer> You have 2 extra revisions:
[19:54] <Lo-lan-do> (I may have to tell clients that it's supposed to work :-)
[19:54] <jelmer> commit on branch1
[19:55] <jelmer> started branch1
[19:55] <jelmer> You are missing one revision(s):
[19:55] <jelmer> commit 4 on trunk (after branching)
[19:56] <jelmer> Lo-lan-do: clients as in business clients?
[19:56] <jelmer> 'evening bialix
[19:56] <Lo-lan-do> Yes
[19:57] <bialix> jelmer: 'evening
[19:57] <bialix> 1.1 is delayed?
[19:58] <jelmer> bialix: we think so, but I haven't seen any news about it from Martin
[19:58] <brilliantnut> isn't that a common question today?
[19:59] <bialix> um?
[20:01] <brilliantnut> I was asking the same thing a couple of hours ago.. I wanted to move our code from CVS, and we're waiting for 1.1
[20:03] <bialix> your're using windows?
[20:04] <brilliantnut> me? yes...
[20:04] <brilliantnut> umm...
[20:04] <bialix> because otherwise bzr 1.1rc1 is good enough, IIUC
[20:04] <brilliantnut> I could reboot into linux, if you like.. :-P
[20:05] <bialix> no, IIRC there is one pending patch required for Windows for 1.1
[20:05] <brilliantnut> hmm... our server is going to be on linux, but 12/13 members of our dev team are on windows, so we have to wait for the 1.1 release yet.
[20:06] <bialix> and last time I moved from CVS  I used cvsps-import plugin, but it works for me only on Cygwin
[20:06] <brilliantnut> hmm.. no problems there, we've tried that out on 1.0, and worked like a charm.
[20:06] <bialix> you're planning to use smart-server?
[20:08] <brilliantnut> yeah, we're planning to use bzr+http with ldap authentication on http, but we ran into some issues when trying that out with 1.0, and there was (at that time) a server and client pending which would fix the specific issues that we were facing... we checked again with 1.1rc1, but we still have that problem.
[20:10] <bialix> is this patch helps to you: http://bundlebuggy.aaronbentley.com/request/%3C20080108055207.GA9962@steerpike.home.puzzling.org%3E ?
[20:12] <brilliantnut> hmm, not sure.. but don't think so.
[20:12] <Lo-lan-do> jelmer: Sent, thanks
[20:13] <brilliantnut> hmm, so you're saying this is the only patch pending since 1.1rc1?
[20:13] <bialix> brilliantnut: hmm. if this patch does not help, then what is your problem actually?
[20:14] <bialix> brilliantnut: I'm not sure actually, but looking at the page http://bundlebuggy.aaronbentley.com/ I don't see anything windows-specific and targeted to 1.1
[20:26] <bialix> luks: 'evening
[20:26] <luks> hey
[20:26] <bialix> how are you?
[20:27] <luks> little bit busy lately :/
[20:27] <bialix> I sent you mail recently. asking about sip and compiling new C++ code in QBzr
[20:28] <luks> yep, sorry for not replying
[20:28] <bialix> My little research leads me to conclusion that I need full Qt
[20:28] <luks> it needs full pyqt install for 'setup.py build'
[20:28] <luks> but it should be still usable without compiling anything
[20:29] <bialix> yeah? I don't try it yet without compiling
[20:29] <luks> I've kept the python code for now
[20:29] <bialix> I build sip myself, but then it say it need pyqtconfig or something similar and then I'm gave up
[20:29] <jelmer> what's this sip thing I keep seeing in relation to qbzr? It's not the voip protocol, is it?
[20:29] <bialix> no :-)
[20:30] <bialix> it's like a SWIG but Qt-oriented
[20:30] <luks> sip is the tool to generate python bindings for c++ libraries
[20:30] <jelmer> ah, nice
[20:30] <luks> more or less like swig, but without the pain :)
[20:30] <bialix> luks: I'm not sure about last point :-)
[20:31] <luks> pyqtconfig is part of the pyqt installation
[20:31] <luks> it's probably not included in the binary installe
[20:31] <luks> r
[20:32] <bialix> yeah, but to building pyqtconfig I need qmake
[20:32] <luks> right
[20:32] <bialix> and I don't find where I can just download it without full Qt
[20:33] <luks> you can use the binary installer for qt, but you need the full devel setup to build pyqt
[20:33] <luks> but as I said, building the c++ code is not required for now
[20:33] <bialix> seems overcomplicated for me
[20:34] <luks> it isn't easy to get it running on win, I know
[20:36] <bialix> luks: working from sources without compiling is working for me
[20:38] <luks> I'm planning to write the diff view in c++, because currently is scrolls very slowly
[20:39] <luks> after that, it probably won't work without compilation
[20:39] <bialix> I understand
[20:57] <brilliantnut> bialix: I'm sorry, I think I missed your response to my last message if there was any... my net connection is a bit flaky.. :(
[20:58] <bialix> here is backlog http://bzr.arbash-meinel.com/irc_log/bzr/2008/01/bzr-2008-01-12
[20:58] <brilliantnut> thanks.
[20:59] <bialix> I'm asking you about your problems with 1.1rc1
[21:00] <brilliantnut> oh, apparently my connection went down earlier than I thought..
[21:02] <brilliantnut> bialix: no, I don't think I can find the specific patch that we were waiting for on that page right now.. but it had something to do with using bzr+http specifically
[21:02] <brilliantnut> bialix: even currently, we have been able to make bzr:// work, and http:// work, but not bzr+http://
[21:02] <brilliantnut> then again, maybe we didn't try hard enough this time yet.. :-P we're waiting for 1.1 before spending a night on it.. ;)
[21:03] <bialix> you need to ask spiv or vila about bzr+http
[21:03] <bialix> I'm just build win installers
[23:30] <rjek> OK.  Anybody with any bzr-svn fu?
[23:30] <rjek> rjek@necrosis:~/bzr$ bzr branch svn://svn.rjek.com/rjek/public/colloquy/trunk
[23:30] <rjek> bzr: ERROR: /rjek/public/colloquy/trunk is not a valid Subversion branch path.
[23:30] <rjek> similar error without the /trunk
[23:32] <Rashomon> Hi all. I'm wondering if you know of any good web-based bzr viewer? (like git-web for example)
[23:32] <Peng> Rashomon: Loggerhead, webserve, bzrweb.
[23:32] <Rashomon> Peng:  Do you prefer any one before the other?
[23:33] <Peng> Rashomon: Never used 'em. :D Loggerhead is the most advanced but also very heavyweight (TurboGears).
[23:33] <Peng> Well, I dunno if the most advanced part is true.
[23:33] <Peng> But I think of it as the primary viewer.
[23:34] <rjek> What's TurboGears?
[23:35] <Peng> rjek: Major Python web framework.
[23:35] <jelmer> rjek: try removing ~/.bazaar/subversion.conf and trying again
[23:38] <rjek> jelmer: OK.
[23:39] <rjek> jelmer: OK, that managed it.
[23:39] <rjek> Ta.
[23:39] <rjek> Although now there's another problem.
[23:40] <rjek> Recently, the svn depot was rearranged slightly, and the place I'm trying to branch was svn mved
[23:40] <rjek> bzr appears to only have history since that move.
[23:40] <Kinnison> Oh well, that's a pity
[23:40] <Kinnison> bzr_access in contrib/ can never work
[23:40] <rjek> Rather than including history all the way back.
[23:40] <Kinnison> the SmartSSHClient
[23:40] <Kinnison> the SmartSSHClientMedium will always pass --directory=/
[23:40] <Kinnison> sux
[23:40] <jelmer> rjek: that may be right. You will have to readjust the branching scheme bzr-svn uses
[23:41] <rjek> Is it possible to tell bzr to branch an svn depot at a specific svn changeset number?
[23:41] <rjek> jelmer: I have no idea what that means, much less how to do it.
[23:41] <rjek> Basically, the trunk used to be in /colloquy/ and it was svn mved to /rjek/public/colloquy/trunk/
[23:42] <jelmer> rjek: what do you mean with "depot" ?
[23:43] <rjek> Sorry, perforce terminolgy that's less typing than "respository" :)
[23:43] <rjek> depot == respository
[23:43] <Kinnison> or even repository
[23:43] <jelmer> ahh
[23:43] <fullermd> I keep my code in a resplendatory.  It makes it look more important.
[23:43] <rjek> heh
[23:43] <jelmer> rjek: for help about branching schemes, see "bzr help svn-branching-schemes"
[23:44] <rjek> Certianly better than a suppository.
[23:44] <rjek> Yes, I read that
[23:44] <jelmer> :-)
[23:44] <fullermd> Well, that's why I don't use svn, see...    ;)
[23:45] <jelmer> fullermd: bzr has repositories, too :-)
[23:45] <rjek> jelmer: I read it, and still have no clue.
[23:45] <rjek> For example, I don't understand why it isn't already working, which puts me in a poor position to fix it.
[23:46] <jelmer> rjek: the branching scheme determines what paths in the svn repository bzr will consider to be branches
[23:46] <fullermd> Yeah, but it doesn't have suppositories, and that's the important thing.
[23:46] <jelmer> rjek: originally it was set to the default /trunk, /branches/*, /tags/*
[23:47] <rjek> jelmer: Right.  So how do I tell it the svn mv from /foo/ to /rjek/public/foo/trunk is such a branch?
[23:47] <jelmer> rjek: it's now probably set to /jek/public/colloquy/trunk
[23:47] <jelmer> rjek: it will have to consider both /trunk and /jek/trunk/colloquy/trunk branches
[23:47] <rjek> There was no /trunk
[23:47] <Kinnison> hmm, no jam :-(
[23:47] <rjek> And there still is no /trunk
[23:48] <jelmer> /colloquy/trunk then
[23:48] <Kinnison> jelmer: I think you and rjek are talking at cross-purposes
[23:48] <jelmer> rjek: try running "bzr svn-branching-scheme --set <repository-url>"
[23:48] <rjek> jelmer: There was no /colloquy/trunk
[23:48] <Kinnison> I think he must have run svn mv .../colloquy .../rjek/public/colloquy/trunk
[23:49] <jelmer> and then make sure both the original and the new branch paths are listed there
[23:49] <jelmer> Kinnison: ah, ok
[23:49] <rjek> Yes.  /colloquy was moved /rjek/public/colloquy/trunk/
[23:49] <jelmer> rjek: so just make sure /colloquy and /rjek/public/colloquy/trunk are listed there
[23:50] <rjek> listed where?  In what syntax?
[23:50] <jelmer> each on a single line
[23:50] <jelmer> when running "bzr svn-branching-scheme --set <svn-repository>"
[23:50] <rjek> I'm still completely lost.
[23:51] <jelmer> have you tried running "bzr svn-branching-scheme --set <svn-repository>"?
[23:52] <Rashomon> one more question. when you are using sftp to checkout or commit stuff to your server, I take it that you use some sort of pubkey? If I need to specify a specific username, how do I do that?
[23:52] <rjek> I don't understand what that will do yet.
[23:52] <jelmer> rjek: it edits the list of paths in the Subversion repository that bzr-svn will consider branches
[23:53] <rjek> ah right, it opens an interactive editor.
[23:53] <jelmer> rjek: Since Subversion has no notion of branches itself
[23:54] <rjek> That looks more promising.
[23:55] <Odd_Bloke> Rashomon: sftp://<user>@<server>/<path>
[23:55] <Rashomon> alright, that was easliy solved ;)
[23:55] <Rashomon> Odd_Bloke: So, if I want to make sure my own commits are sent to the server right when they're done, is that done by the bind command?
[23:57] <rjek> jelmer: That appears to be doing the right thing.  Ta.
[23:57] <Kinnison> jelmer: now you've fixed rjek's problem, fancy fixing mine? The bzr+ssh protocol always passes --directory=/ which means that contrib/bzr_access is useless and it's the one thing which is currently making bzr a viable possible switch for someone I know
[23:57] <Kinnison> jelmer is God tonight, and hopefully can do no wrong :-)
[23:57]  * Kinnison crosses his fingers
[23:59] <jelmer> Kinnison: sorry, I'm afraid I'm not as godlike as I would like to be in that area..
[23:59]  * jelmer has a look at bzr_access