=== herzel76 [i=herzel@gateway/tor/x-0fce8468103591d3] has joined #bzr [12:05] New bug: #137387 in bzr "Strange error message decorating the output of bzr status" [Undecided,New] https://launchpad.net/bugs/137387 === Basic_py is now known as Basic [12:18] lifeless: sorry to interrupt your deep hacking. it seems all that's stored in the index layer (the values) are integers. do we actually want to store arbitrary strings? === phanatic_ [n=phanatic@3e44ad9e.adsl.enternet.hu] has joined #bzr === jam-laptop [n=jameinel@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net] has joined #bzr === jam-laptop [n=jameinel@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net] has left #bzr [] [12:30] keir: there is a layering concern here [12:30] right now there is a boolean and two ints stored in the product values [12:31] lifeless, i see [12:31] I would be ok with making them into structured data rather than strings if there is a tangible win; otoh it makes the index less able to be reused - e.g. the pack-names index will need to be different [12:31] lifeless, i am just wondering, because it is potentially useful if there is a fixed-size-data case [12:31] (it currently stores 4 ints) [12:32] in my attempts to compress data structures, i've been known to reuse the lower bits of pointer addresses to store booleans :) [12:33] my other question: are most uses repeated traversals? [12:33] and why is it in the code you posted above, that it only traverses the first one? [12:33] our knit deltas are deltas against one parent [12:34] there are two parent-lists per node in the .tix [12:34] one parent-list is the per-file graph, which is unrelated to compression [12:34] the other parent-list is for the compression code [12:34] what does tix stand for? [12:34] and the compression code forms a tree, not a graph, so there is only ever 0 or 1 nodes [12:34] 'text index' [12:35] ok [12:35] I don't know what the most common traversal is [12:35] so there is an index for the compression code? [12:35] or most common query pattern I should say [12:36] for .rix its probably breadth first repeated queries on the first node-reference list [12:37] for .iix it will probably be compression-sequence lookups - repeated queries following the compression parent === jml [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr [12:37] for .six it will simply be large set queries for (all revisions being pulled at once) [12:37] I'm trying to modify my bundle for bug #52479 to work on local branches as well as remote ones. However, I'm struggling to find a way of working out where an unbound branch is committing to (with a bound branch I just use Branch.get_bound_location()). What's the best way to do this? [12:37] Launchpad bug 52479 in bzr "Message at the end of commit for bound branches" [Wishlist,In progress] https://launchpad.net/bugs/52479 [12:37] for .tix it could be compression-sequence lookups, or it might be file-graph searches [12:37] Odd_Bloke: branch.base ? [12:38] aaaag! i just hit ctrl-L and logging is off in my xchat [12:38] does someone have a log of the last few hours? [12:38] Odd_Bloke: in commit it should simply be 'committed to %s' % master_branch.base [12:38] Odd_Bloke: you shouldn't need to make any calls about bound branches === keir stomps on xchat for not having logging on by default. [12:39] keir: there is one on the web I believe [12:40] no one else has logging on? [12:40] i was going to paste our chats into my notes and tidy it up [12:40] keir: there is not a separate index for compression; the compression code uses the second node-reference list to form the compression-tree [12:40] lifeless: Yeah, my one year of CompSci Java had me only looking at methods. :/ I'll modify it as such. [12:40] keir: its layering - the index layer is agnostic for the exact use its put to, which has allowed me to use it about 3 different ways so far [12:41] lifeless, i don't know what a compression-tree is [12:41] lifeless, yes, i understand. [12:41] lifeless, however i think it is reasonable to add a 'my values are 8 bytes' flag to the graph builder [12:41] keir: I don't know how to describe it differently. I've tried twice [12:42] We store a given byte-sequence as either a full copy or as a line based deltas against another byte sequence [12:43] lifeless, ok, so that is a compression tree. i understood that, just not that it was named 'compression tree' [12:43] well we don't have a ideal name for it [12:43] its not a graph [12:43] though a graph can store it [12:43] which is how I fit it into the GraphIndex structure [12:44] and i imagine the compression tree, in typical use cases, has a very low branching factor [12:44] given that the index builder only has to output data when the index has all its entries added to it, I don't see why you add a flag telling it how long the values are: you can determine that by inspection during finish() [12:45] keir: the compression tree for inventory is about 4 for every one [12:45] erm [12:45] thats wrong,t ahts the ratio of non-mainline to mainline [12:45] best thing to do is to query it yourself and see for a live repository :) [12:46] true! [12:46] you could report on this for inventories and texts - .iix and .tix [12:46] now [12:46] byte-sequence reconstruction is performance critical for many operations [12:46] what does that mean? [12:47] byte-sequence reconstruction [12:47] I've been referring to 'texts' in an ambiguous way [12:47] texts can mean 'something in the .tix index' or it can mean 'any sequence of bytes we have stored in the repostiory' which is a superset of the first meaning [12:47] so I'm disambiguating now to be clear [12:48] ok [12:48] reconstructing things like the contents of an inventory or the contents of a given file version is a common operation [12:48] and when its slow it multiplies in effect [12:48] 'bzr checkout mozilla' for instance constructs 55K byte sequences which are delta compressed [12:49] ah! so i imagine that's slow [12:49] so that will be following the compression tree for 55K texts in the .tix and 1 inventory from the .iix [12:49] but ideally, there is a pack with a fulltext only a few deltas behind, correct? [12:49] so for .tix and .iix getting the nodes from the compression tree for a single node is a very common operation [12:50] well fulltexts are put in when the deltas add to about the size of the full text [12:50] so a big text gets more fulltexts between deltas than a small text [12:50] erm switch the words there [12:50] yes, i understand. [12:50] ok [12:51] is it often that many files are queried? [12:51] lets see [12:51] for one of my projects, astrometry.net, we use some very clever branch-and-bound algorithms to compare two trees; one is our index, and one is constructed at query time [12:51] branch and checkout will queries size-of-tree nodes for the compression graph [12:52] merge will query size-of-difference * two [12:52] so in those cases it may be possible to do better than N * (index lookup) [12:53] pull does a merge under the hood [12:53] so the only time branch is not equivalent to cp -R is when there's a shared repo, and you are only branching one of the branches? [12:53] same with update [12:53] branch is never equivalent to cp -R [12:54] ok. i fail to see why [12:54] if there is no shared repo we do a clone, which spiders all the data and verifies [12:54] in cases where it's not a shared repo [12:54] so just cp -R + md5check [12:54] you as a user can do that [12:54] we dont [12:54] you might be mounting sftp over fuse for instance [12:54] ok. just because of portability? [12:55] being on a file:// url doesn't guarantee data integrity [12:55] you might have a lot of unreferenced data [12:55] ok, right. my question is more one of what is the fundamental operation, and in non-shared branching, it is just copying raw bytes. [12:55] and we don't copy that - if you make a new branch it only contains the data referenced [12:55] ok [12:55] to make a new branch we: [12:56] exactly, which is why it is not the case for shared repos, because you only branch one of the severa branches, and the shared repo contains all revs [12:56] - ensure there is a repository that can be used at the branch. In the shared repo case we find that up the containing directories. In the non shared repo case we create it. [12:56] - we perform a data fetch from the source branch's repository for the revisions referenced by the branch [12:57] - we create a working tree of the tip of the branch [12:57] for a shared repository the fetch operation fast-paths and just asserts that the data requested is in fact present [12:59] ok [01:02] If you have more questions ping; I suggest getting some of the live indices and exmaining them playing with them etc, perhaps instrument to record the sequence of calls or something then use bzrlib and see what's asked for [01:03] yeah [01:03] where can i get a big pile of live indicies? [01:04] my repo that I have pointed you at [01:04] ok [01:04] those are all the uses for the index right now? [01:04] or follow my dogfooding instructions from the list [01:04] and make your own pack based repo [01:04] yes, they are all the uses [01:04] course, we aren't finished [01:04] so as a client let me be clear - the scope is-a-changing :) [01:05] (but not much I hope) === poolie_ is now known as poolie === mw is now known as mw|out === herzel76 [i=herzel@gateway/tor/x-7a2349dcd7b2cadf] has joined #bzr [02:09] poolie: still on the phone ? [02:09] now serving #72 [02:09] lifeless: can we exploit that most of the keys have large common prefixes? [02:14] because of what we are storing, a radix tree for the keys might not be crazy [02:16] poolie: got a patch for you [02:17] The form of the keys is not guaranteed. imports from git, for example, may have revision ids of "git:%(hash)s". [02:18] http://paste.ubuntu-nl.org/36388/ [02:18] also, i'm not sold that we want multiple adjacency lists for each node; why not use multiple graphs, with a seperate key/value index? [02:18] abentley, ok. [02:18] Make bzrlib.tests.TestCase use super() in setUp and tearDown, and fix a small typo that fucks up emacs syntax highlighting. [02:19] poolie: poolie need anything else for this patch? It's fairly trivial. [02:19] (the super stuff is needed now for some Launchpad test case) [02:19] keir: Gnu Arch imports have a common prefix. bzr-svn 3 does. Dunno about bzr-svn 4. [02:20] what's a reasonable size for a preamble? [02:20] i figure there's going to be no way to avoid reading at least a few hundred bytes from the start of each index [02:21] I think lifeless has been talking about reading 64K at a time. [02:21] it seems to me that you can shrink down the size of the index if you separate the key/value part from the key->(key)* part [02:21] (for remote access, that is) [02:21] yes, of course [02:22] So you would want that 64K to include the preamble and a sizeable number of recent keys. [02:23] ddaa, did you post it to the list? [02:23] ahem [02:23] no [02:23] I do not plan to [02:23] I do not have time to read the bzr list really. [02:23] spiv is looking at it now [02:24] hrm [02:24] I'll have him get through the hoops. [02:24] ddaa: hmm. [02:25] hmm, so after a pull, locally an index gets built from the data that got pulled? (for pack repos anyway) [02:26] ddaa: the problem is it's an incompatible API change. Other people might have subclasses with multiple-inheritance involving bzrlib.tests.TestCase already. === spiv thinks [02:27] if they do, then they're bust [02:27] ddaa: not at all [02:27] because all the other test classes that derive from TestCase use super() already [02:28] keir: thats a possibility, consider benchmarking on live data [02:28] As far as I can tell, there is no way to look at it and not see it as a bug, because TestCase clearly is the one breaking the rules. [02:28] Well, bzrlib doesn't multiply inherit from TestCase via different routes. [02:28] keir: you can use my dgofooding insutrctyions to convert repos like thepython import on launchpad to packs [02:28] ddaa, posting a patch to the list does not require that you read everything on the list [02:29] ddaa: python's TestCase doesn't use super FWIW [02:29] it's enough to just say 'please cc me on replies', or pick out that one thread from the list [02:29] ddaa: There are at least a few places we use MI in the test suite: the bundle tests and the versionedfile tests come to mind. [02:29] lifeless: if that's a problem, then all the classes that derive from bzrlib.tests.TestCase should be changed not to use super() [02:30] lifeless, ok. it seems reasonable that there may be multiple indexes with the same keyspace, and possibly differerent or same data [02:30] ddaa: is this impacking you in some way ? [02:30] what specific problem does it cause? [02:30] ddaa: what lifeless said. Using super in bzrlib.tests.TestCase isn't going to solve all uses of inheriting from two different unittest.TestCase classes. [02:30] lifeless: yes, I want to MI from a TestCaseWithTransport and one existing test class in the Launchpad test suite that derives from unittest.TestCase. [02:31] ddaa: best to state what you actually want it to do and why it doesn't currently work === lifeless bows out there are enough eyeballs on this [02:31] -->commit performance [02:31] ddaa: I don't think that can work reliably, sadly. [02:31] ddaa: because you have diamond inheritance [02:32] i wish i'd inherited diamonds :) [02:32] ddaa: but part of the inheritance graph is unittest.TestCase, which doesn't use super. [02:33] spiv: it is not a problem because there is no diamond above unittest.TestCase [02:33] I *think* the fact that unittest.TestCase is the notional common root might be enough to make it work with current Python. [02:33] lifeless, actually, i have a crazy idea. what about having a mapping var length keys -> fixed size id's. then we can support key tuples as (id1, id2) rather than the full string [02:33] But they've changed the MRO before and could easily do it again. [02:33] In general though, I think inheriting from multiple TestCases isn't a good thing to do. [02:33] lifeless, then we get to have 1 place that lists all the file id's and one place that lists the rev id's [02:34] spiv: I find it unlikely that a MRO change would affect a simple case like this one. [02:34] Because you' [02:34] keir: thats roughly what the current index does, the fixed size ids are byte offsets in this case [02:34] keir: so its a reasonable thing to do [02:34] re likely to get difficult interactions even without super. [02:34] spiv: okay, I give up on this patch and just somehow refactor my code. [02:34] lifeless, ok. it looks like the file id's and rev id's are used in multiple idx's; so this would be a big win on large indexes [02:34] ddaa, i'd suggest instead [02:34] I see too much reviewer argument ahead. === ryanakca [n=ryan@ubuntu/member/ryanakca] has joined #bzr [02:35] well, to back up [02:35] you need some bzr-related setup and some lp-related setup done for a single test? [02:36] for bzr commit, it's 'bzr commit -m "commit message" --fixes:lp:bugnumber' ? [02:36] poolie: in a nutshell, yess [02:38] i'd be inclined to do it by [02:38] refactoring the parent classes so that all the setup methods are individually callable [02:39] which should generally be the case already for bzr [02:39] then having your setUp just do what it wants [02:39] i think relying on super to do all this is confusing/problematic [02:39] yes, that what I meant by "refactor my code" [02:39] spiv, do you agree [02:39] I it just mildly disappointing because MI would have been the natural way to do it IMO. [02:40] Yes, I think that would probably work. [02:40] A hackish way to do that is simply: [02:40] def setUp(self): self.borrowedTest = OtherTestCase('foo'); self.borrowedTest.setUp() [02:41] hah, i am redesigning berkely db [02:41] poolie: BTW, you probably want to clean out the uses of super() in setup() and tearDown() methods of bzrlib.tests.TestCase descendants then. [02:41] :) [02:41] Which doesn't save you from conflicts in the setup (e.g. if both tests want to tweak global state like logging, os.environ, or the cwd). [02:41] But that would be a problem with MI anyway. [02:42] poolie: either use it everywhere, or use it nowhere. The current situation is just a problem waiting to happen IMO. [02:42] Also, you don't get easy access to custom assertion methods on the OtherTestCase. [02:42] spiv: which would be an annoyance in this case. [02:43] google says "authentic python handbag" :) [02:43] ddaa, if you want to remove them in fixing this that's ok with me, [02:43] or file a bug [02:43] ddaa, please use the regular review mechanism if you want bazaar changes [02:43] keir: bdb doesn't have graph awareness; thats a key part of this index logic [02:44] and we will try to make it work efficiently for you [02:44] poolie: ack [02:44] ryanakca: what are you asking ? have you read the help? [02:45] if you try it and you think it is eg taking too much time, raise that with one of us or on a company list [02:45] lifeless, i know :) [02:45] lifeless: --fixes=ARG mark a bug as being fixed by this revision. [02:46] lifeless: ARG being something. Anyways, I don't need to anymore, since the Ubuntu upload closed them [02:46] do we want indexes to scale > 4gb? === n2diy [n=darryl@wlk-barre-208-103-148-76.dynamic-dialup.coretel.net] has joined #bzr [02:46] or rather, is it reasonable to expect to be able to fit the entire index in memory? or should i design assuming you can't do that [02:47] ryanakca: at the end of 'bzr help commit' [02:47] See also: bugs, uncommit [02:47] ryanakca: so 'bzr help bugs' [02:47] lifeless: thanks [02:51] lifeless: shall I merge Watkins' patch without test case refactorings? === jml [n=jml@203-113-250-169-static.TAS.netspace.net.au] has joined #bzr === Rotund [n=rotund@d28-101.rb2.lax.centurytel.net] has joined #bzr [02:56] New bug: #137407 in bzr "messy error if BZR_HOME does not exist" [Low,Triaged] https://launchpad.net/bugs/137407 [03:01] we seem to have a lot of reviews bounced recently [03:01] because of disagreements about indenting [03:01] but there is no clear statement in either hacking or pep8 about just what is allowed [03:01] abentley: sure, that was speculation or I wouldn't have done bb:approve === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr [03:03] morning [03:05] poolie: clearly, the reviewer gets to choose the indenting style >:-) [03:05] ok, that works :) [03:12] Well, I'm not sure about double-indenting when doing line-wrapping. Because you're already down to 67 characters if you're in a method body, 63 if you're in a try block, 59 if there's a loop inside the try block. [03:13] lifeless, what is the 'absent' field used for? [03:15] New bug: #137412 in bzr "Code duplication in tests.blackbox.test_commit" [Undecided,New] https://launchpad.net/bugs/137412 [03:16] keir: it records keys which are not in the index but are referred to by a key reference [03:16] I don't line 8-indents on line wraps [03:17] here are the possibilities as i see them: [03:17] a- indent under the delimiter (opening brace or whatever) [03:17] b- indent 4 spaces [03:17] c- indent 8 spaces [03:17] lifeless, hmm, what is it used for? in the next layer up? [03:17] d- indent 0 spaces [03:18] I would prefer a where practical, otherwise b. [03:18] a is nice [03:18] a bit more laborious to maintain [03:18] well, for non-emacs users [03:19] :) [03:19] keir: no, consider an index with one entry and one key-reference list: ('key1',), 'value', [('anotherkey',)] [03:19] keir: iter_all_entries() needs to yield ('key1',), 'value', [('anotherkey',)] [03:20] keir: iter_entries([('anotherkey',)] ) needs to yield nothing [03:20] anotherkey is not present in the index [03:20] it is absent [03:20] ok [03:20] have a look at the serialisation tests [03:20] but aren't keys listed by their position in the file? [03:20] have a look at the serialisation tests [03:21] lifeless, how about allowing a/b? [03:21] spiv ^^ [03:21] c? [03:21] poolie: we currentl use a or b as people feel comfortable [03:21] i thought you didn't like c? [03:21] I don't like c [03:21] i sometimes use c as that's what vim seems to like [03:21] i am happy to change though [03:22] vim is on crack [03:22] vim rocks! [03:22] i just want it settled rather than being rehashed in every review [03:22] sure [03:22] it is probably configurable in vim [03:22] can I ring to bounce an idea [03:22] lifeless, keir: Maybe you can compromise: vim is on crack rocks! [03:22] lol [03:23] abentley, heh [03:23] keir: I speak as a vim user. === bigdog [n=scmikes@79-67-14-216-arpa.cust.cinci.current.net] has joined #bzr [03:28] ok, i just came up with a nice unified way of storing these graphindexes, and i realize it just bakes down to the same thing as a berkely db [03:28] I use a or b. [03:28] how does knowing we're storing a graph help again? [03:29] i mean, i can make the format amenable to readv() wire access, but it's still just storing k,v pairs === ollie_r [n=orutherf@dsl092-164-022.wdc2.dsl.speakeasy.net] has joined #bzr === ionstorm [n=ion@70-58-119-250.phnx.qwest.net] has joined #bzr === poolie_ [n=mbp@ppp112-44.static.internode.on.net] has joined #bzr [03:45] keir: you can group data topologically [03:46] keir: you can reduce latency by adding apis for common graph/tree walking operations where the index layer is able to predict and readahead in the graph order [03:47] and you can dictionary compress key references because we have 'k,v,r' rather than 'k,v' where the key references would be opaque [03:55] alright. time for graphviz [04:03] keir: I don't know if you'll find it useful, but bzrtools includes "graph-ancestry", which uses dot. [04:04] abentley, ok, thanks === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr === bigdo1 [n=scmikes@79-67-14-216-arpa.cust.cinci.current.net] has joined #bzr === jamesh [n=james@220-253-85-85.QLD.netspace.net.au] has joined #bzr === bigdo1 is now known as bigdog === jamesh_ [n=james@canonical/launchpad/jamesh] has joined #bzr === jamesh_ is now known as jamesh [04:55] -> poolie === igc food === jml_ [n=jml@ppp121-44-221-92.lns1.hba1.internode.on.net] has joined #bzr [05:42] jml_, hi? === herzel76 [i=herzel@gateway/tor/x-37b4ca187502a5fb] has joined #bzr === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr === herzel76 [i=herzel@gateway/tor/x-531b9bb3d47019ec] has joined #bzr [06:05] Weird. Someone submits a branch to us, including about new 50 files making up something that we decide not to accept (and so revert|delete). We work further on the branch, then merge it to 'mainline'. We then push to the public repo, and bzr does the endless-small-round-trips thing. [06:06] After thinking about it, I realized that it must be creating new knit files server side for each of those files, because they were in revisions that are in the branch even though the files involved were subsequently deleted. === orospakr [n=orospakr@bas4-ottawa23-1177561563.dsl.bell.ca] has joined #bzr === herzel76 [i=herzel@gateway/tor/x-6d6086fd53966fd1] has joined #bzr [06:23] yes, because it's still carrying the history for those files === jml_ is now known as jml [08:01] New bug: #137449 in bzr "status performance regression compared to 0.17" [Undecided,New] https://launchpad.net/bugs/137449 === hdima [n=hdima@idealer.cust.smartspb.net] has joined #bzr === AfC [n=andrew@office.syd.operationaldynamics.com] has joined #bzr === Lo-lan-do [n=roland@mirenboite.placard.fr.eu.org] has joined #bzr === g0ph3r_ [n=g0ph3r@p57A09D1C.dip0.t-ipconnect.de] has joined #bzr === pygi [n=mario@83-131-6-127.adsl.net.t-com.hr] has joined #bzr === g0ph3r_ is now known as g0ph3r === g0ph3r is now known as dbachran === dbachran is now known as dbachran_ === dbachran_ is now known as dbachran === dbachran is now known as dbachran_ === dbachran_ is now known as g0ph3r === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === mvo [n=egon@p54A67434.dip.t-dialin.net] has joined #bzr === igc food === mwh [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === sabdfl [n=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === Zindar [n=erik@88-110-212-200.dynamic.dsl.as9105.com] has joined #bzr === mrevell [n=matthew@canonical/launchpad/mrevell] has joined #bzr === mwhudson [n=mwh@62-31-157-102.cable.ubr01.azte.blueyonder.co.uk] has joined #bzr === allenap [n=allenap@212.233.37.68] has joined #bzr === fog [n=fog@debian/developer/fog] has joined #bzr === Mez [n=Mez@ubuntu/member/mez] has joined #bzr === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr === asabil [n=asabil@ti0035a340-0802.bb.online.no] has joined #bzr === sabdfl [i=sabdfl@ubuntu/member/pdpc.silver.sabdfl] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr [11:29] uhm, bzr upgrade is not supported over bzr+ssh? [11:29] % b upgrade --dirstate-tags bzr+ssh://bzr.debian.org/bzr/pkg-python-debian/trunk [11:29] bzr: ERROR: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. [11:30] % b upgrade --dirstate-tags sftp://bzr.debian.org/bzr/pkg-python-debian/trunk [11:30] ... finished [11:32] https://bugs.launchpad.net/bzr/+bug/125166 [11:32] Launchpad bug 125166 in bzr "Smart server doesn't suppport upgrading" [Low,Confirmed] [11:33] morning [11:33] with no knowledge at all, it seems like it should be fairly easy to fix... [11:33] mwhudson: ah, thanks. === igc [n=igc@ppp59-167-96-213.lns3.bne1.internode.on.net] has joined #bzr === jnair [n=jayesh@203.123.188.10] has joined #bzr [12:28] dato: thats right === anandn [n=anandn@220.225.40.40] has joined #bzr === yminsky [n=yminsky@user-0cevcqv.cable.mindspring.com] has joined #bzr === Zindar [n=erik@host217-42-238-84.range217-42.btcentralplus.com] has joined #bzr === rschuster [n=rob@e178095055.adsl.alicedsl.de] has joined #bzr [01:02] hi bzr-folks [01:03] i am trying to implement a bzr-fetcher for OpenEmbedded and need your help [01:03] how can I find out the latest revision number of a certain (remote) branch? [01:04] something like 'svn info ' which will contain the line: "Revision: 8404" (for example) [01:06] rschuster: as a command (that is, not using the Python API): bzr revno http://... [01:09] dato: thanks alot thats it! [01:09] rschuster: you're welcome === asabil [n=asabil@62.70.2.252] has joined #bzr === pygi [n=mario@83-131-6-127.adsl.net.t-com.hr] has joined #bzr [01:40] rschuster, note that the revision number is not the most accurate indicator of whether a branch has changed. [01:40] he left already. [01:42] night all === Starting logfile irclogs/bzr.log === ubuntulog [i=ubuntulo@ubuntu/bot/ubuntulog] has joined #bzr === Topic for #bzr: The Bazaar Version Control System | http://bazaar-vcs.org/ | Bazaar 0.90 is out - http://bazaar-vcs.org/releases/src/bzr-0.90.tar.gz | Please complete the Bazaar User Survey - http://www.surveymonkey.com/s.aspx?sm=L94RvLswhKdktrxiHWiX3g_3d_3d === Topic (#bzr): set by james_w at Tue Aug 28 23:38:27 2007 === mrevell is now known as mrevell-lunch === welterde [n=welterde@trujillo.srv.pocoo.org] has joined #bzr === deadwill [n=deadwill@146037.fln.virtua.com.br] has joined #bzr === luks [i=lukas@unaffiliated/luks] has joined #bzr === mw|out [n=mw@189.146.24.28] has joined #bzr === statik [n=emurphy@189.66.188.72.cfl.res.rr.com] has joined #bzr === ddaa [n=david@canonical/launchpad/ddaa] has joined #bzr === bwinton [n=bwinton@mail.phantomfiber.com] has joined #bzr === sverrej [n=sverrej@pat-tdc.opera.com] has joined #bzr === cypherbios [n=cyr@ubuntu/member/cypherbios] has joined #bzr === sverrej_ [n=sverrej@pat-tdc.opera.com] has joined #bzr [03:35] anyone knows how to make the visual studio integration working ? === Ng [n=cmsj@mairukipa.tenshu.net] has joined #bzr [03:57] hey folks. If I push a bzr tree to an sftp:// I obviously just get a .bzr directory there. What magic can I do on the remote end to make it generate the working files too (not automatically, just manually is fine) === mrevell-lunch is now known as mrevell [03:58] Ng: 'bzr update' [03:58] mwhudson: that's what I thought, but it said "No WorkingTree exists for file:///blah/branch/.bzr/checkout/." [03:59] (fwiw, the local bzr is 0.18 and the remote is 0.17) [03:59] oh [03:59] 'bzr co' [03:59] spot on, thanks :) === _logger [n=_logger@adsl-75-51-62-134.dsl.chcgil.sbcglobal.net] has joined #bzr === Demitar [n=demitar@c-212-031-190-120.cust.broadway.se] has joined #bzr === mthaddon [n=mthaddon@canonical/launchpad/mthaddon] has joined #bzr === orospakr [n=orospakr@132.213.238.4] has joined #bzr === mathias_ [n=mathias@chello213047054216.31.11.tuwien.teleweb.at] has joined #bzr === mw|out is now known as mw === grimboy [n=grimboy@85.211.236.250] has joined #bzr === pygi [n=mario@78-0-12-62.adsl.net.t-com.hr] has joined #bzr === tchan [n=tchan@lunar-linux/developer/tchan] has joined #bzr === p4tux [n=p4tux@189.169.92.184] has joined #bzr === fog [n=fog@debian/developer/fog] has left #bzr [] === hsn_ [n=radim@234.114.broadband5.iol.cz] has joined #bzr === mathias_ [n=mathias@chello213047054216.31.11.tuwien.teleweb.at] has joined #bzr === dpm [n=dpm@p54A114D9.dip0.t-ipconnect.de] has joined #bzr === AndyP_ is now known as AndyP === abadger1999 [n=abadger1@65.78.187.68] has joined #bzr === james_w [i=jw2328@jameswestby.net] has joined #bzr === dpm_ [n=dpm@p54A114D9.dip0.t-ipconnect.de] has joined #bzr [06:54] Lo-lan-do: The non-lhs push issue has been fixed in the 0.4 branch of bzr-svn === mario_ [n=mario@78-0-25-35.adsl.net.t-com.hr] has joined #bzr === mario_ is now known as pygi === Ng [n=cmsj@mairukipa.tenshu.net] has left #bzr [] [07:01] jelmer: Excellent, thanks. === bwinton [n=bwinton@mail.phantomfiber.com] has left #bzr [] === sverrej [n=sverrej@tul-1x-dhcp016.studby.uio.no] has joined #bzr [07:13] how difficult would it be to implement git-style branch switching? [07:13] so that you only have 1 working tree, which you can switch between branches with a bzr command [07:14] keir: that should be possible to implement using a plugin [07:14] wow, really! [07:14] and wouldn't be too hard I think [07:14] ok, that is high on my list after writing a new index layer [07:14] i definitely prefer git's way of working regarding branches [07:15] There's already a bzr switch command... [07:16] bzr switch takes a to_location though [07:17] is in not in the main bzr? [07:17] no, it's in bzrtools [07:17] bzr help commands | grep switch -> empty [07:17] aah, ok [07:17] you'd want it to take a tag I guess [07:17] no, a branch name [07:17] right, so you'd want to write a plugin that: [07:17] keeps a list of branch names in a file somewhere under .bzr/ [07:18] the file would simply contain a dictionary with "branch name -> revid" mappings [07:19] how is a branch represented in a shared repo now? [07:19] and the plugin would have a ocmmand to list the branches, one to add a branch to the file and one to change the active branch [07:19] keir: there's a .bzr/branch/last-revision file that contains the tip of the branch [07:19] that's all there is to a branch [07:20] ok [07:20] or a .bzr/branch/revision-history for v5 branches [07:20] so in a shared repo, it's .bzr/branch_name_here/revision-history? [07:20] keir: you can simply call Branch.set_last_revision(revid) to change the tip of a branch [07:21] keir: no, in the branch's .bzr dir [07:21] aah, ok === sverrej_ [n=sverrej@tul-1x-dhcp108.studby.uio.no] has joined #bzr [07:22] repository doesn't know about it's branches [07:22] right, i understand [07:23] so i'd basically have to make a new branch format [07:23] and by format, i mean placement of branches [07:25] no, you should be able to use the current branch format [07:25] the only bit of data that is missing atm is the list of branches [07:26] the active branch can still be in .bzr/branch === Herodes [n=chatzill@ppp193-100.adsl.forthnet.gr] has joined #bzr [07:28] I get this : [07:28] "working tree is out of date, run 'bzr update' [07:28] bzr: ERROR: exceptions.AssertionError: 257 != 1" [07:28] how can I fix it ? [07:29] it is a new branch that I have ,... [07:29] and I am merging a branch with 257 revisions,.. [07:29] so I suppose I need to push up the revision I have to 257... [07:30] keir: my plugin does stuff like that, so I can give you pointers as well when you do it if you like. [07:41] I found the problem.. [07:42] I was using the "bzr merge", where I needed to use "bzr branch". Sorry for spaming.. === jelmer_ [n=jelmer@157pc196.sshunet.nl] has joined #bzr === jelmer_ is now known as jelmer === gldnspud [n=gldnspud@72.171.93.139] has joined #bzr === relix [n=david@d51A403F3.access.telenet.be] has joined #bzr [08:03] Heya [08:03] I'm trying to version my whole /home directory [08:03] so I was in my home dir, and used "bzr init" [08:04] then I tried "bzr add" and after changing a couple of filenames that made it crash, it said "(amount) files ignored. Add them by name to version them" [08:04] I can't go over these thousands of files to add them "by name" [08:04] how can I add them? [08:04] I tried bzr add *; bzr add /david/home/; bzr add ./; bzr add; [08:04] none works [08:06] what files are they? dot files? (bzr ignored would tell you) === yml [n=yml@put92-2-82-224-221-145.fbx.proxad.net] has joined #bzr [08:07] hello [08:07] good evening [08:07] ah thanks james_w [08:08] apparantly one of my ignored settings filters a couple of thousand files [08:08] so it's entirely my fault and I feel pretty dumb now having wasted your time :s === mrevell is now known as mrevell-dinner [08:08] relix: no problem. [08:09] what is the easiest way to remove some of the revisions of a project hosted on launchpad? [08:11] if this is not possible. how can I delete a branch? [08:12] yml: remove completely, or just rewind a branch? [08:12] remove [08:12] you have to delete the branch. However if launchpad use shared repositories even doing that might not get rid of it completely. [08:13] or remove all the revision below revno60 [08:13] I mean remove the revision from 1..59 [08:17] or is it possible to create a branch from an exiting repository for all the revno>60 and the this new branch to do bzr push --overwrite === herzel76 [i=herzel@gateway/tor/x-7b23387c61280b42] has joined #bzr [08:20] relix: I don't recommend doing that in bzr, if you're going to include dot directories like .opera. I did, and committing got really slow after a few months. OTOH, the bzr guys are working on improving that, so maybe it won't be so bad in the future. === dato [n=adeodato@tarrio.org] has joined #bzr [08:33] yml: i don't think you can do what you suggest even locally can you? [08:34] mwhudson : I don't know I am trying many combination but so far I have not found anything that do what I would like to do. [08:35]