[00:53] ddaa: How goes? [00:55] hello [00:55] well, I'm on leave [00:55] been poking around with bzr-git [00:56] managed to get a simple blackbox test "bzr log" working [00:56] now I'm kind of stumped trying to get "bzr pull" to work [01:03] it seems a lot of stuff needs InventoryEntry.revision to be set [01:03] but bzr-git cannot easily set this to a meaningful value [01:05] okay... it seems just using the current revision might work [01:05] now need to find the text sizes... [01:07] I messed around with bzr-git a long time ago. [01:08] Watch out for the hashes; AFAICT, they are *not* the fulltext sha1s. [01:09] ew [01:09] thanks [01:09] thinking of it, that makes sense [01:09] they are the hashes of the git representation, not of the data itself [01:10] Also, I don't know if bzr-git still uses the quilt "bindings", but you're better off writing your own, a la pybaz. [01:10] I'm working on jam's branch [01:10] Ah. [01:10] it does not depend on stgit anymore [01:10] Ah, stgit. Sorry. [01:11] a couple of days ago, I tried to make a transparent git:// transport [01:11] I've just implemented a new merge algorithm that should match beat weave merge on criss-cross, and equal three-way the rest of the time. I'm very excited. [01:11] now, I'm pretty sure it cannot be done in the current state of git [01:11] ...match *or* beat... [01:12] that sounds really cool [01:12] one merge to rule them all :) [01:12] Oh, absolutely. Merge should Just Work to the maximum extent possible. [01:12] at least a git:// transport would require reimplementing all the git client code [01:13] so it does not depend on the existence of a local .git directory :( [01:13] Yikes. [01:13] What about treating remoted gits as a kind of smart server? [01:14] btw: http://code.aaronbentley.com/bzr/bzrrepo/lcamerge if you're interested. [01:14] vanilla git servers pretty only know how to transfer packs [01:14] as far as I can tell, it works like in a rsync-like manner [01:15] first there's a negotiation phase where client and server determine what objects are needed [01:15] then the server builds a pack and sends it over the wire [01:15] the problem is that all the existing git code just work off filesystem structures [01:16] and has nice things like hardcoded exit() calls... [01:16] tla, how I haven't missed you ;-) [01:16] exactly :/ [01:17] also, all the code assumes that sockets can be used as file descriptors [01:17] It sounds like a tough problem. [01:17] so it just cannot work on win32 [01:17] Is this hacking launchpad-related? [01:17] no, that's off hours hacking [01:18] sounds like a lot of trouble, so I just gave up on this for now [01:18] local bzr pull would be nice enough [01:19] What can bzr-git do these days? [01:19] run bzr vis :) [01:19] but now it has some tests [01:20] That's it? Still? [01:20] it cannot even display diffs [01:20] I'm pretty sure my branch could do checkouts. [01:20] * ddaa tries [01:20] ddaa: couldn't you just invoke git to download the data onto the local drive and then manipulate from there? [01:21] foom: that's the line I'm exploring now [01:22] ddaa: sounds sensible. :) [01:22] but that means the data has to be duplicated on disk, that's less than ideal. [01:22] yeah, but at least you don't have to rewrite git. [01:22] ideally, all you'd need to do would be "bzr branch git://foo", like bzr-svn does. [01:23] abentley: my branch cannot do lightweight checkouts [01:23] but OTOH I pretty much rewrote all of your stuff already [01:23] you should have written some tests :) [01:23] lifeless didn't! [01:24] Why should I start? [01:24] * ddaa looks up despair.com [01:25] That one would do [01:25] http://despair.com/tradition.html [01:26] I love their mug. [01:26] lol [01:27] One nice thing about git is you should be able to do really fast tree comparisons. [01:29] it's not clear that bzrlib will make this any easy [01:29] building a proper inventory pretty much requires building the whole tree [01:30] I'm planned to use "git archive" to write a tarball to a pipe, and then process it incrementally. [01:31] that seems to be the only way to get multiple text_size in a single git call [01:31] pyarch taught me that if you are naive with CLI bindings, you get to pay excessive process spawning costs [01:32] the unix-scripting model does not play well with object orientation [01:33] ddaa: I would expect you can implement _iter_changes without too much API friction. [01:33] We are working hard on making the inventory itself go away. [01:33] From the public API, I mean. [01:34] * fullermd is looking forward to inventory reworks. [01:34] what is _iter_changes useful for? [01:36] diff, merge, status, etc. [01:36] that's a RevisionTree method? [01:37] Yes, a Tree method. [01:37] It is implemented on InterTrees, so it can be specialized for particular tree types. [01:37] this interstuff is still a bit magic to me [01:37] I get the general idea though [01:38] double-dispathc [01:38] Right. [01:39] time to go hack this TarFile thing [01:39] Happy hacking! [02:31] bzr: ERROR: mismatched lock context and write group. [02:31] aroo? [02:35] jelmer: ^^ I got that doing a bzr svn-import [02:45] Wow, I've never even heard of that one. [02:46] mtaylor: that has been fixed in the 0.4 branch [02:46] jelmer: hrm. and here I thought I was using 0.4 :( [02:47] jelmer: 0.4 is the one that goes with bzr 1.0 right? [02:47] no, that's 0.4.5 [02:47] 0.4 is a bzr branch [02:47] the fix is not in any release [02:47] ah. ok [02:48] hehe [02:48] Repository KnitRepository is not compatible with repository KnitRepository [02:48] :) [02:48] abentley: happens if you close a write group that has already been closed [02:49] mtaylor: you need a rich-root repository [02:49] jelmer: Ah. [02:49] lifeless really should have made sure the repr still distinguished between those types. [02:50] and it would be great if the error messages mentioned the type of repos like "rich-root" instead of the class name... [02:50] as the mapping is not always evident [02:50] yeah, we need to fix that [02:51] I actually said I was going to send in a patch for that [02:51] but haven't gotten round to it yet unfortunately [02:52] I have a long list of similar items [02:53] mtaylor: what sort of items? [02:53] not for bzr... just a list of patches I need to add to things that I haven't gotten around to [02:53] ah :-) [02:53] sorry ... english broke on me there. :) [02:57] grmbl [02:58] hey ddaa [02:58] tarfile generated by git causes TarFile to try to seek backwards at some point... [02:58] how's bzr-git going? [02:58] mh... I think it's actually a case of "oops, int overflow" [02:58] ah, having fun \o/ [02:59] trying to efficently extract data out of this git thingy [02:59] it uses tar internally?? [03:00] I've been told it's fast, so I'm reluctant to spawn it for. every. single. inventory. entry. to get the text_size and sha1 [03:00] and it seem the only way to get it to spit multiple files at once is using git-archive [03:00] could you make text_size and sha1 properties and do lazy evaluation? [03:00] that produce a tarfile on a pipe [03:01] mh [03:01] mh ? [03:01] would that really be a gain? [03:01] In some situations, yes [03:01] The issue is that I would like bzr pull to work somewhat efficently [03:02] ok, no point in that case [03:02] and I GUESS it will have to check every single inventory entry [03:02] I'm already going to spawn "git cat-file" once for every file [03:02] I'd rather not do it twice... [03:04] heh, oops [03:04] kind of weird though that tarfile ends up with a stream pos of 2315264L [03:04] no performance improvements by using bzr-git then? [03:04] git is heavily fs-based [03:05] it does not play nice with object-based bzrlib [03:05] bzr-svn can in some rare situations actually be faster than bzr native [03:05] in this sense, svn is probably less hostile [03:05] bbl [03:05] in that it actually tries to be a library [03:19] jelmer: [03:19] oh crap [03:19] he's gone [03:20] I tried the most recent bzr-svn from 0.4 [03:20] and now I'm getting: [03:20] NoSuchId: The file id "7924@3c33494c-61f7-0310-86b9-b90697347e9d:branches%2Fdevelopment-2.0:server%2Fmerlin%2FWEB-INF%2Fsrc%2Fcom%2Fmysql%2Fetools%2Fscratch" is not present in the tree etc. [03:25] jelmer: it seems like spaces are not allowed in file ids, is that right? [03:25] I mean, is that correct? [03:34] ddaa: I can't remember. It doesn't seem like a good idea, at least. [03:37] how would they have gotten in the file id though? [03:38] because I'm defining the file ids [03:39] using the file name as a file id [03:40] anybody know when the fink port is going to get some love?? http://pdb.finkproject.org/pdb/package.php/bzr-py25 [03:41] it's still at 0.18 :( [03:44] ddaa: so does that mean I'm just screwed if I've got spaces in file names here? I know I've got those elsewhere? [03:45] don't worry [03:45] normally bzr generate random ids [03:45] my problem is specific to my own hacked up experimental branch of bzr-git that eats little kittens at breakfast. [03:45] so it's just a bzr-svn issue then? ah... [03:45] not at all [03:45] I thought you were commenting on my error from above? [03:46] :( [03:46] I don't pretend to have a clue about debugging bzr-svn [03:46] I have looked just enough at the code to realize how complicated it is. [03:47] it works in an amazingly diverse number of situations [03:50] wow! I got bzr pull to actually do something [03:51] w00t! [03:52] now I need to find a way to avoid marking every file modified at every revision [03:53] that might help storage efficiency a bit, I guess [03:54] mh... passing bzr check would be a first step [04:10] w00t [04:10] well, it seems like the tarfile approach does not work... for some reason yet unknown [05:41] abentley: lol; I wrote the core of bzr-git at europython between ddaa's and my talk, and the lightening talks that afternoon [05:42] hey [05:42] I hate that bzrlib cannot guess the revision of an InventoryEntry [05:42] I just want to stuff it the file data, and leave it to find where it was introduced. [05:44] lifeless: And bzr-hg? Did you write tests for that? [05:45] abentley: some I think [05:45] abentley: my initial goal was to bring up enough stuff that the interface tests kicked in; but they were at the time very hostile to non bzr native things [05:45] not much less hostile now I suppose [05:45] Hehe. [05:46] Are you enjoying the time off? [05:46] yah [05:46] until I got net a couple days ago I hadn't thought code for nearly a week [05:46] totally different mind set [05:47] and I'm trying not to get into it now either; I am helping squid migrate to bzr though ;) [05:47] we should change this message [05:47] Risky business, that. [05:47] bzr: ERROR: Tags not supported by BzrBranch5('file:///home/robertc/source/baz/plugins/bzrtools/ab-trunk/'); you may be able to use bzr upgrade --dirstate-tags. [05:47] Actually using bzr for other things tends to bring the urge to tweak it. [05:47] migrating or thinking ? [05:48] Both, I guess. [05:48] http://wiki.squid-cache.org/Squid3VCS [05:50] Why are you branching and binding rather than checking out? [05:51] IIRC checking out there will create a tree [05:51] Ah, so treeless bound branches actually have some value for you. [05:52] join #cake [05:54] lifeless: I see you mention "bzr patch", but I don't think you mention installing bzrtools. [05:57] lifeless: Also, I now have "merge --preview" working locally. [05:57] nice! [05:57] a -r spec sounded like a great way to present it [05:58] I can imagine bzr diff -r merged:../trunk [05:58] lifeless: remind me what revision of a directory entry should be? [05:59] It does, but it doesn't really leave room for listing file conflicts, so I've just gone with merge --preview for now. [05:59] ddaa: its in the docs; don't want to think too hard bout work stuff right now [05:59] I think it's more important to specify merge type than diff type, too. [05:59] docs? [05:59] abentley: this is a use case for diff and status being on deltas not against wrking trees - then conflicts can come up naturally for this :) [06:00] anyhow [06:00] I'm off for now [06:00] ciao [06:00] ciao [06:05] bye === _mathrick is now known as mathrick [10:15] What's that thing called that's like a redirect, where a file tells bzr to look somewhere else? How can I create one, and is it worth using it over an HTTP redirect? [10:15] Is no-working-trees relevant in a non-shared repo? [11:17] hey all, is there any tool to see the size of the changes in the various revisions? [11:21] what sort of format? bzr diffstat (from the plugin of the same name) might be what you're looking for [11:25] ok, bzr 1.0 uploaded to backports.org for etch [11:27] bob2, thanks. will look into that. [11:36] I guess I'm trying to see the size of each commit [11:36] so I can identify the commits where some massive files were dumped into the repo [11:39] if in a repository I want to change the mtime of actual files in the tree to that of the latest revision that touched them, can somebody give me a crash course how to find that information for each file? [11:40] Peng: echo "Bazaar-NG Branch Reference Format 1" >.bzr/branch/format [11:40] Peng: Peng echo -n "http://url.com/path/to/the/other/branch" >.bzr/branch/location [11:41] Peng: the sole advantage would be that after people branch from that location, next time they pull they would go directly to the referenced branch, not the original one [11:42] dato: Clients use the new URL? [11:43] yes, the new url is storead as parent_location, from what I've seen [11:43] so the behavior is quite different from an HTTP redirection [11:44] Might not be a bad idea to update parent_location for HTTP permanent redirects too... [11:45] Which version was the reference format introduced in? Do any other files need to be in branch/? [11:45] only those two afaik, but remember .bzr/branch-format as well [11:45] Right. [11:51] Haha, nice. I need a \n at the end of format but not at location. [11:51] * Peng notices that dato's example followed that. [11:51] :) [11:53] The descriptions on the bzr plugins page could be a tad bit more complete. [11:55] Blah, I'll stick with an HTTP redirect. [11:56] It's not like anybody has copies of my branches anyway. :) [11:59] Thanks for you help, dato. [11:59] np === bigdo1 is now known as bigdog_ [14:30] jelmer, around? [14:31] acuster: hi [14:31] hey [14:31] just tried doing my first push to the svn [14:31] which consisted of adding two comment markers to one file [14:31] it's taking a long time and sending lots of data so I presume I'm doing something wrong [14:32] should I be able to do just: bzr push http://svn.geotools.org/geotools/trunk/gt ? [14:32] if I am in the trunk/gt directory locally [14:33] actually, in the working/gt directory locally [14:35] acuster: It can only push full branches, not parts [14:35] acuster: What is your branch of locally? [14:35] I branched trunk [14:35] then locally branched to make a working [14:35] then did a checkout [14:36] commited to the checkout [14:36] in that case, you should be able to push to http://svn.geotools.org/geotools/trunk [14:36] and want to push back up [14:36] do I have to be in trunk/ locally as well? [14:36] no [14:36] tanks [14:36] trunk/gt would be fine as well [14:36] thanks [14:44] is this a really expensive operation? If so, is it only expensive the first time? [14:44] depends on what its saying [14:45] it may well be expensive the first time if you have a lot of other branches [14:45] two branches locally only [14:45] seems like a lot is going over the network [14:46] acuster: no, I mean in Subversion [14:46] bzr doesn't remember that it came from that same source? [14:46] Does the Subversion repository contain any other branches? [14:46] ah, yes, the Subversion is a total mess [14:46] in that case, it could be a bit slow the first time [14:47] thanks [14:47] but a lot faster after that [14:47] I'm very worried about hurting the svn [14:47] since it's delicate and being used by several groups for production [14:48] you can run with -Dcommit -Dtransport to see what its doing [14:48] (it will write info to ~/.bzr.log) [14:49] Thanks! [14:50] time for another talk [14:50] back later [14:50] ciao [15:22] jelmer, when you get back: The FAQ looks out of date for 1.0 re how to upgrade a repo. You should probably mention the 'rich-root' meme to match bzr 1.0's 'bzr help upgrade' info. === bigdo1 is now known as bigdog_ [18:44] Hi. I'm on WinXP with Bazaar 1.0. When I run bzr checkout bzr://localhost:9500/branch, I get the error message: bzr: ERROR: socket.error: (10055, 'No buffer space available'). Any ideas? [18:45] There are 2 revisions in the repository. The first is 73,975,380 bytes. The second is 5,972,504 bytes. [18:45] bzr checkout --lightweight does work, but I want the history locally. [18:49] I think there was some issue with the bzr protocol and large socket buffers that blew up Windows. [18:50] Using a dumb transport like http or sftp should fix it. It may be fixed in the dev head (to be 1.1) or not; can't remember. [18:51] why does bzr report files including the working directory? It breaks the standard unix cut/paste of dbl click on the file name; middle click to paste [18:51] it usually does not, here [18:52] fullermd: Hmmm... I was hoping to set up nothing more than the smart server. I'm behind https with client authentication. I haven't tried bzr to see if it supports client certificates. Mercurial does not. [18:52] paset the command you used and its output, please [18:52] Maybe I'll try to build dev head and see what happens. [18:52] oh, I get it; it's reporting the file name from the root of the tree not from the working directory [18:52] acuster: right [18:53] hmmm [18:53] I believe most commands can be restricted to the current subdir [18:53] if you add "." at the end of the command line [18:53] jjensen: Yeah, try that. You don't need to actually install it; you can just branch it and run it out of its branch dir. [18:53] It'll still show paths relative to the root. [18:56] it's too bad --- a tiny slowdown in workflow; I wonder if it's fixable [18:57] maybe I'll understand enough later to make a suggestion [18:57] Shared repos a la init-repo save space if what's under them are branches of one project. Any gain (other than shorter URLs) for putting multiple projects in the same source language under one such repo--i.e., init-repo .../hub, init .../hub/proj1, init .../hub/proj2, ...? [18:57] I won't often need multiple branches per project, and those could be .../hub/proj1.exp1 and the like. I'm also wondering how to list branches under a shared repo, but I bet I missed something simple there. I'm just starting with Bazaar, but with much enthusiasm, coming from years of CVS and a bit less time with Subversion. [18:59] you won't gain anything by putting multiple unrelated branches in the same repo [18:59] Will I lose anything (space or efficiency)? [19:00] Not sure, you might lose a bit of efficiency. [19:01] To get all the branches in a repo, you can use "bzr branches" from bzrtools [19:01] though it does not work with all transports [19:01] You'll lose a little, from having bigger indices etc. to search through. Unless they're rather large projects, you probably won't notice. [19:02] Generally, a repository does not know of the branches it contains (so you can rename branch with just "mv"). The "bzr branches" command basically does something like "find -type d -name .bzr", so it requires a listable transport, and can be rather slow. [19:03] typically, http is not listable (unless the server supports webdav). [19:04] jelmer: can I reuse inventory entries among inventories? [19:05] I mean, can I assume that bzrlib will not modify my inventory entry objects? [19:06] I look forward to nested trees. :) Projects are small, but there are many of them. [19:09] I guess I'll try bzr init-repo --no-trees .../hub (actually .../var/bzr) and then bzr init repos under it just so everyone can create projects with a simple bzr init, or leave /var/bzr empty and do bzr init-repo /var/bzr/proj1 + bzr init /var/bzr/proj1/main etc. for each project--but the latter will look like overkill to the version-control-uninitiated around here :) [19:27] fullermd: Sadly, with bzr 1.1.0.dev.0 on python 2.5.1.final.0 (win32), I still get error: (10055, 'No buffer space available'). :( [19:28] But it is nice that bzr head works out of the box like that without installing any extra Python modules. [19:29] As a possible alternative, is there a binary build of bzr-svn I can download? [21:04] re [21:04] acuster: thanks [21:04] acuster: that has already been fixed in 0.4, will be updated for 0.4.6 [21:04] ddaa: not that I know [21:04] that's okay [21:05] I think I found a correct and reasonably efficient way to compute entry.revision without involving a monster inventory cache. [21:05] How to report an issue in documentation? [21:08] juh: Please file a bug on launchpad - http://launchpad.net/bzr [21:08] ok [21:09] jelmer: so, I have got a super-experimental bzr-git that looks like it can actually pull [21:09] how do you think I should release this without have innocent users start to use it for real work? [21:09] ddaa: w00t \o/ [21:10] ddaa: sure, as long as there's the usual warnings about eating your cat, etc. [21:10] * jelmer would be happy to do testing [21:10] is there a testsuite? [21:10] I mean, what's the best in-your-face way to put those warnings? [21:10] jelmer: the pull stuff is not tested [21:10] it's pure binge hacking [21:10] ddaa: in the README and the announcement I'd say [21:10] there is a embryonic test suite that covers stuff up to "bzr log" [21:14] jelmer: done [21:17] juh: thanks! [21:20] Prompt three times with caps lock and lots of exclamation points before doing any command. :) [21:20] Also, adding a GTK+ bit to do big flashing red text would be good. [21:21] New bug: #179292 in bzr "Wrong order of new branch command in Quick Start Guide" [Undecided,New] https://launchpad.net/bugs/179292 [21:23] ddaa: rev the namespace [21:23] ddaa: in particular if you think you might not be 'done' use an experimental namespace [21:24] ddaa: /win 17 [21:28] ooh, lifeless has knowledge about David's irssi windows? [21:28] no [21:28] in lifeless's world, everybody uses irssi :) [21:29] I would like to see the common bits of cvsps-import, bzr-hg and bzr-git commonalised [21:29] and bzr-svn for that matter [21:30] * ddaa forces himself to stop tweaking and release the code [21:40] jelmer: https://code.edge.launchpad.net/~ddaa/bzr-git/bzr-git.pull [21:43] That's announcement enough, I think. Feel free to point other interested hackers to it. [21:44] At this point, I think it needs an InterRepository to stop the memory use from growing too much. [21:45] bazaar 1.0 with packs safe to put into production? [21:49] ddaa: Thanks! [21:49] I'll give it a try [21:49] Now, I'm going to remove some of the cruft that accumulated in the past 24 hours of binge hacking. [21:50] jelmer, the FAQ has been fixed? /me was talking about: http://bazaar-vcs.org/BzrForeignBranches/Subversion/FAQ [21:51] ah, ok [21:51] that's just an online copy of the FAQ in the branch [21:51] I should move the bzr-svn homepage away from the wiki at some point so I can automate it [21:51] ah, then it just needs a bump, should be easy [21:51] and no longer have to update those pages manually [21:55] or perhaps editmoin could support uploading wiki pages at some point >-) [21:55] hsn_: sure is [21:55] jelmer: you can automate changes to the wiki [21:56] jelmer: its just a trivial post [21:56] lifeless: sure, but scripting that is more work than running rst2html on samba.org [21:57] jelmer: or perhaps just make the wiki page into a redirect to the codehosting source browser ? :) [21:57] well, that doesn't do rst rendering yet :-/ [21:58] anyhow, time for the hacker jeopardy [21:58] back later [21:59] lifeless: btw, I don't know what the experimental flag in BzrDirFormatInfo is used for [21:59] but it's still set to true for some of the packs formats [21:59] (in bzrlib/bzrdir.py) [22:29] jelmer: its ui fluff [22:32] what's funny with self-hosted VCS [22:33] is that you can be pretty sure that the self-hosted repo is going to contain a large sample of the interesting corner cases :) [22:33] * ddaa has just been bitten by having to escape control chars around revno 3000 in the git repo. [23:03] packs format seems to use lot of CPU power [23:03] interesting factoid from #git [23:03] apparently the die() call can register handlers [23:04] so it's possible to recover from die() using longjmp() [23:04] cehteh did so [23:05] I usually need to recover from longjmp() :p [23:06] ddaa: you may recover but have malloc structures inconsistent [23:06] ddaa: which is to say, you may 'recover' [23:07] apparently, git uses malloc in unusual ways [23:07] this does not surprise me [23:07] only for large allocations (presumably mmaped), and then uses custom allocators [23:08] lifeless: how does longjmp() cause inconsistent malloc structures? [23:08] longjmp doesn't [23:09]