[00:21] bzr: ERROR: Repository KnitRepository('file:///.../.bzr/') is not compatible with repository KnitRepository3('file:///..../.bzr/') [00:21] Does the svnplugin make KnitRepository's instead of KnitRepository3? [00:23] no, it uses KnitRepository3 but standard bzr uses KnitRepository [00:23] oh, why is that? [00:23] you can upgrade a repository to the first by running 'bzr upgrade --dirstate-with-subtree' [00:23] forward compatibility on bzr-svn's side [00:24] cool, thanks [00:28] I love bzr! :-) [00:28] The horror of using svn because of googlecode.. for weeks! [00:38] Peaker: so access the svn repos from bzr [00:39] arjenAU: What I really wanted was shared branches though, and now I hope to have that with launchpad [00:39] arjenAU: I want development to go into branches instead of messing up trunk all the time [00:39] not just by me, but by codevelopers [00:40] a heavy checkout is really just a repo+branch pulling/pushing from/to another branch on every commit, whereas a light checkout is really just a branch ptr, right? === mw is now known as mw|out [01:03] If I just delete the working tree (when it has no uncomitted changes ofcourse), I can just restore it with update, right? So when I'm done with a branch, I can remove the working tree to save some space until I use it again, right? [01:04] if that is true, I think I might need/write a plugin that verifies there are no uncommitted changes, cleans up and deletes all the files it can restore later [01:12] You delete the working tree with remove-tree, and recreate it with checkout [01:12] remove-tree won't remove altered files (or non-versioned files) [01:15] fullermd: ah cool thanks [01:16] then it seems I dont have to write a plugin :-) [01:33] hmm, bzr hosting on launchpad seems to force me to upload the entire repo for each branch I make there. Where do you guys host your bzr branches such that creating a new hosted branch is cheap and doesn't require pushing the entire history? [01:34] When I C-c (SIGINT) the bzr push to launchpad, I got TooManyConcurrentRequests: The medium '' has reached its concurrent request limit. Be sure to finish_writing and finish_reading on the currently open request. [03:03] How do you run "bzr serve" over ssh? How is access control done? [03:06] Peaker: bzr+ssh:// just connects via SSH as normal, and runs the "bzr serve" command (actually it gives it a couple of arguments). [03:06] spiv: oh, I thought it bzr+ssh connects to an sshd already running [03:06] Peaker: access control is done entirely by the SSH server and filesystem; i.e. normal user accounts. [03:06] (unless you want to write a custom sshd...) [03:07] It's pretty similar to how svn+ssh:// works, AIUI. [03:07] so the path given to bzr+ssh://path-here must be absolute, not relative, right? [03:08] (relative would be relative to user's home dir, I'd suppose) [03:11] To set up permissions of who can access my bzr repository via bzr+ssh, I'd need root access to create a group I suppose. I hate unix security... [03:22] do you think if I install a local copy of bzr in my homedir on the sourceforge shell server they'd be mad? :-) [03:24] Peaker, you can always use sftp [03:24] that'll be a bit slower, but won't require bzr on the remote side [03:27] jelmer: thanks that works :) I wonder if that will piss them off.. heh [03:30] doesn't seem like shell.sf.net is a usable file host for bzr, its taking ages to do anything [03:31] where do you guys host your shared branches? [03:31] sftp is slower than bzr+ssh in any case, unless you use it with packs (new data format in 0.92) [03:31] I host them on my team's shared server or launchpad [03:31] my ubuntu is still packaged with 0.90.0 [03:32] jelmer: but if you want to make a new branch on launchpad you have to push the entire history again [03:32] yes, but I only use launchpad for smaller things [03:32] how big is your history? [03:34] there's 40MB in my repository/ [03:34] if that's a good measure [03:34] but what's the number of revisions? [03:34] this is bug 41415 in launchpad apparently [03:34] 452 [03:34] Launchpad bug 41415 in launchpad-bazaar "supermirror sftp server does not support hosting bzr repositories" [Wishlist,Confirmed] https://launchpad.net/bugs/41415 [03:36] according to the bug I can use sftp to explicitly create repositories [03:37] well, you can on an ordinary sftp server, but not on launchpad [03:37] weird, how does their sftp prevent it? [03:38] only allows you to create certain directories [03:38] to prevent you from using launchpad for general-purpose (non-bzr branches) hosting [03:42] I see [04:09] can I tell a branch to move its head back without creating a new revision that's identical to previous revisions? [04:10] I could create a new branch but the branch is already there and advertised as a main branch.. [04:11] also can I decide that a bunch of changes I've been making should not commit to this branch but instead go to another branch? [04:12] Without bzr diff | patch in-new-branch ? [04:13] Peaker: "cd ../new-branch; bzr merge --uncommitted ../old-branch" [04:13] spiv: thanks! [04:13] no way to get a branch to throw a bunch of the last revisions to become ghosts though? [04:14] well actually I made a branch that contains them now, so they wouldn't be ghosts [05:11] does bzr have nested checkouts? (if I want to split my repo into 3 for each of the components) [08:55] Peaker: partially [08:55] Peaker: it's somewhat supported, but still experimental [10:20] New bug: #158596 in bzr "`bzr info -v` is not working if WT4 is locked." [Undecided,New] https://launchpad.net/bugs/158596 === LarstiQ_ is now known as LarstiQ === weigon__ is now known as weigon [11:36] mwhudson: ping [11:36] jelmer: hi [11:36] mwhudson: Can you please try pushing your pydoctor branch to svn again, using the latest and greatest bzr-svn ? [11:37] jelmer: ok [11:37] jelmer: should i use bzr.dev? [11:37] I've reproduce the property bug and fixed it [11:37] yes, either bzr.dev or 0.92rc1 and bzr-svn's 0.4 branch [11:38] what's the url of the bzr-svn branch? [11:38] it seems that i haven't installed it again since my hard drive died [11:38] http://people.samba.org/bzr/jelmer/bzr-svn/0.4 [11:39] or lp:bzr-svn [11:39] ok [11:50] ah, lovely, a segfault when i C-c-ed the fetching revision info step [11:54] jelmer: hm, seems to be doing the 'finding branches' thing twice [11:55] hmm, it shouldn't do the finding branches more than once [11:56] it's doing it a third time now [11:57] this is during a push or a pull? [11:57] push [11:58] but you've never pulled this particular branch before? [11:59] jelmer: not on this machine no [11:59] i can do that first if you like [11:59] jelmer: http://rafb.net/p/fVHbyE18.html [12:00] and noe [12:00] mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr get http://codespeak.net/svn/user/pydoctor/trunk [12:00] bzr: ERROR: Not a branch: "http://codespeak.net/svn/user/pydoctor/trunk". [12:00] mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr get svn+http://codespeak.net/svn/user/pydoctor/trunk [12:00] bzr: ERROR: Not a branch: "svn+http://codespeak.net/svn/user/pydoctor/trunk". [12:02] what does "bzr svn-branching-scheme http://codespeak.net/svn/user/pydoctor/trunk" say? [12:02] oh we [12:02] er [12:02] wrong svn url [12:03] mwh@grond:pydoctor$ ~/src/bzr/bzr.dev/bzr svn-branching-scheme http://codespeak.net/svn/user/mwh/pydoctor/trunk [12:03] bzr: ERROR: No repository present: "http://codespeak.net/svn/user/mwh/pydoctor/trunk/" [12:06] try: [12:06] bzr svn-branching-scheme http://codespeak.net/svn/ [12:06] here it says: [12:06] */*/*/trunk [12:06] */*/*/branches/* [12:06] */*/*/tags/* [12:07] i have one level less of */ [12:07] maybe this is because i fed it a bogus url to start with? [12:08] ah, yeah, that may've confused it if there are also branche swith just two levels of parent directories [12:08] probably [12:09] it's a fairly chaotic repo :) [12:09] simply removing "scheme = " from ~/.bazaar/subversion.conf will make it try again [12:10] or rather, set it to "trunk3" [12:12] ok, i managed to get the branch now [12:14] pushing is doing the finding branches thing again [12:15] more than once? [12:16] not yet [12:16] it's going slowly this time [12:21] i guess the extra level of */ gives it a lot more locations to consider? [12:22] jelmer: http://rafb.net/p/9RE7Or87.html [12:24] mwhudson: yeah, it's very inefficient for your sort of repository [12:24] mwhudson: does it break like in a reproducible way? === mrevell is now known as mrevell-lunch [12:27] jelmer: will let you know :) [12:34] jelmer: yes, seem reproducible [12:37] mwhudson: ok, guess I have a new bug to work on then.. thanks! [12:38] jelmer: i guess this is some kind of corruption in the repository [12:38] jelmer: but it ought to be possible to ignore stuff over in other parts of the tree from where i want to work? [12:41] mwhudson: corruption in the svn repository you mean? [12:41] mwhudson: yes, bzr-svn should be able to ignore that bit but it can't yet [12:42] jelmer: yes === mrevell-lunch is now known as mrevell [13:23] jelmer: ping === mw|out is now known as mw [14:15] New bug: #158690 in bzr "ls --non-recursive PATH : no list" [Undecided,New] https://launchpad.net/bugs/158690 [14:42] schierbeck: pong [14:45] lifeless: ping [14:46] vila: pong [14:46] wow :) [14:46] I saw you used transport.list_dir [14:46] Can't you avoid it ? [14:46] yes, in a write operation [14:47] (it's in Rev 2949: * Obsolete packs are now cleaned up by pack and autopack operations.) [14:47] not without more round trips than it's worth. [14:47] oh, I know where it is. [14:47] that means wedav plugin will never be able to do that :-/ [14:47] webdav supports listing [14:48] err, let me check that :-) [14:48] we used it on tla for writing over webdav [14:48] IIRC its :search [14:56] has anyone had some weird problem with "cannot access lock file" on win32? [14:56] * jroes forgets to just google and find bugs on launchpad [14:57] looks like an extension to RFC2518... would be far more work to marshall the request and extract the useful bits in the response... I think the sort tem answer will be to activate directory listing on the http server and lightly parse an index.html (i.e. implement an ad-hoc list_Dit) :-/ [14:57] s/Dit/dir [14:58] I thought that with packs you somehow maintained the list of files created on the server, why can't it be used for obsolete ? Recovery handling ? [14:59] And the other hand webdav is happy to delete a whole tree, (i.e. the obsolete dir even if not empty) [15:04] we shouldn't rm the obsolete dir because that would trash permissions [15:04] gee, s/sort tem/short term/ around three lines above [15:06] permission handling is already messy when using a web server... [15:09] So far, the webdav plugin stay simple because it avoids parsing xml in any response, having to implement list_dir wil kill that, I just have no idea when or even if I will take into account [15:09] well packs are still experimental [15:10] so, after reading "bzr help working-trees" I'm beginning to have trouble following the point of bzr when you are on a machine that is not running a webserver. is this the general consensus or am I not understanding right? [15:10] Said otherwise, my question is: should I just kill webdav plugin *now* or do you think you can avoid using list_dir ? [15:10] the tla code for list_dir was pretty darn trivial [15:10] lifeless: pointer ? C ? python ? [15:10] jroes: I think you are not understanding right [15:10] vila: apt-get source 'bazaar' and look for pfs_http.c [15:11] well, see, if I'm just a developer on my development machine, and I want to have my branch publically accessible for friends/colleagues/the public to branch and merge from, I need to push my changes to a separate machine via SSH [15:11] from what I've read, unless I use a plugin, I have to login to the machine after every `bzr push` and run `bzr update` [15:12] jroes: you don't need to run update for other people to be able to pull from it [15:13] well, what happens when I commit a new change in my local branch and then I run push again? [15:13] then bzr updates its metadata, and ifthey do a pull they will getyour commit [15:15] ok, so then the message I am seeing when I push is just a warning, and not an error based on what I'm actually pushing at this point? [15:15] you're getting the warning because you have a working tree on the remote machine [15:16] "This transport does not update the working tree of: sftp:/etcetcetc/. See working-trees for more docs" [15:16] we assume you have some reason for doing that and thus let you know that it will not be updated [15:16] if you don't need a working tree there, then bzr zap-tree is your friend [15:16] ok, so I must have accidentally done something on the remote box like a bzr commit of some sort? [15:17] I'm trying to figure out what I did to turn it into a working-tree, what kind of operation would do that? [15:18] * jroes will grep his .shell_history [15:19] lifeless: hehe, sure, pfs_dav.c trivially implemented pfs_directory_files by..... relying on neon :-) [15:19] vila: oops, well. [15:20] how can I publish a bzr+ssh branch for all users that has a nice path and not some ://my_comp/var/hosting/bzr/... ? [15:20] lifeless: no worries. just wanted to keep you informed, that if you can still avoid it... [15:20] Peaker: maybe you can get symlinks or hardlinks to work. I don't think I could get symlinks to work, but I might have some permissions problems [15:20] lifeless: ... or not avoid it, but knows about the consequences for webdav [15:21] * vila back to fixing bugs :) [15:21] vila: well there are some issues; I will mail the list some thoughts for packs2 [15:21] ok [15:22] lifeless, vila: what about having a Transport.clean_directory() [15:22] which for most transports is implemented as lifeless does [15:22] and for webdav could be [15:22] rmtree() + mkdir() [15:23] jam-laptop: feels a bit bloatwarey [15:23] I agree, but it solves the problem [15:23] It is a fairly specific request [15:23] And means we don't expose 'list_dir()' to higher levels [15:24] Certainly from a smart server perspective we would want it to be done solely on the remote side, though that would be handled by the fetch() logic I presume [15:25] right [15:25] jam-laptop: but doesn't address the permission bit lifeless talked about (I'm still unclear about what you worry though) [15:25] lifeless: where is this zap-tree? even google only found 3 results (and 2/3 were irc quotes from you) [15:26] :) [15:26] vila: well, as you said, if they are accessing over webdav, then permissions are pretty much just apache:apache [15:26] jroes: "bzr remove-tree" [15:26] zap-tree was an old command [15:26] * jroes nods, thanks [15:26] I think you have to be on that machine [15:26] I'll quiet down now since you guys are in heated developer discussion :) [15:27] jroes: dont' do that :) We have time to solve our issue [15:28] lifeless: any chance of a 0.92rc1 deb today? =-) [15:29] jam-laptop, lifeless : I *thought* the list_dir was... hmmm, would be deprecated one day :) But I also had the impression, at London sprint, that implementaing it for http my solve a range of issues [15:29] vila: it is considered unusable for read-only transports [15:29] but lifeless was only doing this during a write operation [15:29] jroes: remove-machine [15:29] hm. so on my remote machine I ran a "bzr remove-tree" (which I believe completed successfully, since there were no errors), and then on my local machine I ran a bzr push to the remote machine, got an error about branches diverging, so I ran a bzr merge on my local machine merging from the remote machine, and got a "working tree has uncommitted changes" I'm not too sure why, but technically if I just want my two branches to be the same, can I just rm-rf the en [15:29] bleh. ignore me [15:29] the problem being that a bit of server-side configuration may be needed and that it kind of make our dumb support support have some limits [15:30] At the moment, all supported writable transports support listdir [15:30] jam-laptop: gee, cruel again ;) [15:30] jroes: Well, we are letting you know that there is divergance [15:30] you pushed something earlier that you haven't merged [15:30] and you are trying to merge into an unclean tree [15:30] The recommendation would be [15:30] so, in that case it's telling me my -local- tree is not committed? [15:31] or the remote tree? [15:31] "review changes; bzr commit; bzr merge; bzr commit; bzr push" [15:31] that's what I'm confused about I think :) [15:31] jroes: The "changes in your working tree" is because you have local uncommitted changes [15:31] If you want a big hammer [15:31] you can [15:31] bzr push --overwrite [15:31] right, so, bzr commit shows me "no changes to commit" :) [15:31] And then it will throw away whatever is extra in the server side [15:31] I think I will use overwrite, unless I discovered a bug and you guys want me to preserve this state [15:32] vila: I think it is a little odd to have a filesystem that you can write to, but you cannot see the files [15:32] jroes: well, having merge complain about an unclean tree, but commit say nothing to commit is weird [15:32] jroes: save it for a second [15:32] bbiab [15:32] ok [15:33] too bad this particular local machine is windows, I don't think I have a bash_history here to see what exactly I did to repro :| [15:33] C:\Documents and Settings\\.bzr.log [15:34] Or maybe it is in My Documents? [15:34] I don't quite remember where it gets put [15:34] here's a pastebin so you guys can see what I'm talking about, I'll hunt down the log and see if I can copy the branch around and get the same results http://pastebin.com/m12f743c7 [15:35] tbh, I wasn't really having a problem until recently, and I think this has to do with something previous where my repository lock file was unable to be accessed after I failed a merge somehow [15:35] I think we try for "My Documents" [15:35] 'tis in My Documents [15:36] jroes: can you do "bzr status" ? [15:36] Having merge disagree with commit is really weird [15:36] oh, and what "bzr --version" are you using? [15:37] bzr status works, there are a bunch of unknowns and a removed file, and 0.91.0 [15:37] jam-laptop: sure, but it goes for read-only filesystems too :) I'm a lazy guy, so as long as I could maintain the webdav plugin without list_dir and more importantly without parsing zml, I did, if that chnaged, I'll have to take a tour to the drawing board... [15:37] vila: well, we know for a fact that we have http [15:37] vila: and we aren't trying to get list_dir for readonly [15:38] vila: obviously i don't know the webdav protocol [15:38] I offered a semi-cludgy workaround by customizing it at the Transport layer [15:38] but really, we *do* want to delete those files [15:38] I think all the problems really started when I got "ImmortalLimbo: Unable to delete transform temporary directory ..." [15:38] It might be possible to write our own index of "things we renamed into this directory" [15:38] but that can also get out of sync, etc. [15:38] oh, maybe I should have read "Please read the limbo file" :) [15:39] jam-laptop: I understand and don't want to stop bzr going forward, webdav can well be freezed for a while, it's not as if hundreds of projects were using it daily :) [15:40] I was just hoping to push it a bit more as soon as I get auth.ring landed and true https support, now I have just another bigger problem :) [15:41] how bad is zml? [15:41] Is it drastically different from XML? [15:41] lifeless: your latest commit to bzr.dev has its NEWS entry under the old "IN DEVELOPMENT" (0.92); i don't know if the plan is to merge into 0.92, or a new "IN DEVELOPMENT" should have been created. [15:41] its the key to the left [15:42] Or is it like XHTML which is XML, but has specific tags you need to understand [15:42] ReadonlyTransportDecorator doesn't give wonderfully informative error messages [15:42] dato: it's slated for 0.92 [15:42] ok [15:42] pack disk changes:: [15:42] packs2: [15:42] - optional annotation cache [15:42] - remove list-dir? discussion needed on race conditions [15:42] - drop inventory parents data [15:42] packs3: [15:43] - new inventory format [15:43] - arbitrary-parent delta's. [15:43] - 'pack' recompresses [15:43] packs4: [15:43] - new delta-compression [15:43] --- [15:43] jam-laptop: ^ thats a strawman [15:44] what are you thinking as a timeframe for this? [15:44] 1 per month? [15:44] yah, one per release [15:45] What is the timeframe for getting retries working? [15:45] As that would be #1 for me [15:45] soon as you write the code ? :) [15:45] retries don't need a new disk format... [15:45] an alternative strategy for handliing old packs may remove the need to do that though [15:46] ok, I see, I hit that ImmortalLimbo error when merging in a branch with a bunch of files, then I just tried merging with the same branch again and I got an "Unable to obtain lock file" for repository/lock. at which point I panicked (3am), and deleted the repo lock, and subsequently branch lock when I got the same lock error on that as well [15:46] ever since then, I've had that dissonance. so, can I recreate my locks or is my branch entirely busted now? :) [15:46] (jroes: for future reference you can use "bzr break-lock") [15:47] And locks should automatically be replaced [15:48] hm. hmm [15:48] jroes: had the dissonance that "bzr commit" says nothing to do, but "bzr merge" says there are changes? [15:48] (again what does "bzr status" say?) [15:49] yeah [15:49] lifeless: the "leave them in place but mark them absent in the names index" ? [15:49] yah [15:49] bzr status right now shows 1 removed file and several unknowns [15:50] in fact, another developer's branch is in this same state now [15:50] I guess I don't understand why "bzr status" would report changes, but "bzr commit" wouldn't commit them.... [15:51] You aren't doing anything like a partial commit, right? [15:51] (bzr commit just-this-path) [15:51] I don't even know how to do a partial commit [15:51] but awesome I really wanted to know that last night :) [15:55] lifeless: so I agree that the annotation cache should rate high in priority, especially before we have people start mass conversions from knits, and they lose all that data [15:56] I would like to see the extra knit data added [15:56] so that we can make the indicies fully redundant, and able to be regenerated [15:56] I'm not sure where that fits with "drop inventory parents data" [15:56] (but for that you are talking about the inventory ancestry graph, right?) [15:58] And I assume by "pack recompresses" is that you mostly just want the wiring in place so we can see what layouts we want to use [16:01] hmm, so I tried to push the branch to a new location just for fun to see if you guys would run into the same problems if you did a get, and the push was successful, but when I tried to make a new branch I got a weird error about a directory not being empty http://pastebin.com/m3783699b [16:01] hi all [16:02] jam-laptop: right, I'm talking about have compression info only for inventory storage [16:02] jroes, could it be you already had a partly-created branch there? [16:02] jam-laptop: by pack recompresses I mean doing your arbitrary-parent delta logic to get optimal storage. [16:02] I must have really hosed this thing somehow :) the only other problems I had were sometimes I would do a bzr diff and my machine would practically lock up because it was doing diffs on binary files for some reason [16:03] poolie_: in the new remote location? [16:03] both the remote dir poundbzr and the local dir poundbzr did not exist before those operations [16:04] hm [16:05] poolie_: let me get you up to date, here's another pastebin from earlier - merge and commit don't agree on my branch: http://pastebin.com/m12f743c7 [16:06] theoretically you guys should be able to run "bzr branch http://jroes.net/jroes/poundbzr" in /tmp or wherever you like and get the same error I just got about directories not being empty [16:06] I wish this repo wasn't so large [16:08] but I guess I'm wrong because I just branched successfully :) [16:08] jroes: well the url you just gave is giving me a 404 [16:08] Ah, but that is just because you have directory listings turned off [16:08] yeah :) [16:09] http://jroes.net/jroes/poundbzr/.bzr/branch-format still shows up [16:10] ok, so in the parent directory where I did that first bzr branch, I have a .bzr directory, so I must have committed it to something at some point [16:10] which may be the root of all of my problems? :) [16:10] LarstiQ, pingz0rz [16:11] jelmer: pong [16:12] LarstiQ, did you see the discussion on knitpack-richroot on the list? Can you perhaps comment on the state of subtrees? [16:12] jelmer: I am not back to reading mail yet, so no. I'll have a look now. [16:14] LarstiQ: Subject contains "Feedback on migration to bzr" [16:15] hi LarstiQ good to see you around [16:15] jelmer: thanks [16:15] I hope things are going well for you [16:15] jam-laptop: responding on pings and working my way (slowly) through a bzr.dev merge etc [16:15] jam-laptop: reasonably [16:15] jam-laptop: how are you? [16:16] pretty good, a little sleep deprived :) [16:16] not terribly though [16:40] so, it's bad practice to have bzr branches within bzr branches, right? [16:41] jroes: why would you have a branch within a branch? [16:43] I have a src directory branch and then I have a branch for one of the projects [16:44] the src branch is just kind of for keeping track of everything in my src directory for myself, and then the other branches were for the specific projects, but I don't know if this is really necessary :) [16:45] jroes: Ah, I see. My understanding of the Bazaar workflow shows that maybe you should break the src up into individual branches, one per project [16:46] jroes: you can do that, but the containing branch will not track the contained ones just yet, you still have to do that manually. [16:56] jam-laptop: so that strawman works for you? [17:10] jelmer: ping [17:11] schierbeck, pong [17:11] have you looked at my latest logview changes? [17:11] i think it's turning out pretty good [17:11] not yet, sorry [17:11] :P [17:11] will have a look this evening [17:11] great [17:12] what tz are you in? [17:12] +2 [17:12] copenhagen [17:12] ah, ok - same here [17:26] poolie_: the packaging session is at 2 in the room next to the lp room. [17:28] What are they packaging the attendants in, and will there be pictures? ;) [17:37] hi coffeedude [17:38] welcome to the house of fun :) [17:38] abentley: ping; I want to express fetch-ghosts in bzr core; do you think an option to pull/push, or a new command is better ? [17:38] hey lifeless [17:39] I've just droped about 90% overhead in local pack based merges :) [17:40] Well, only 10% to go! [17:41] 3 seconds to merge trivial change between two python full-history imports [17:41] Nifty. [17:42] bit slow still [17:42] we're still doing an inventory upcast/downcast [17:42] I think it should be < 2 seconds eventually [17:43] < 1 second once the journalled inventory/split inventory stuff is done [17:45] That interests me. AIUI, that should really help us with broad trees with deep history, to say nothing of the annoying even on small trees "can't log multiple files". [17:46] yes [17:48] Eggselent. [17:55] New bug: #158774 in bzr "no UI for fetching/filling in ghosts" [Undecided,New] https://launchpad.net/bugs/158774 [18:50] so... .. i'm very new at this, but for now, I just want to import my code into an bzr repo that i have on a remote server, I did the init-repo and init and I have a project.stable which I want to import all the files I currently have in a certain directory.... [18:50] what's my next step? ... check out right? [18:50] Alien_Freak, bzr add [18:50] Why not just create the branch in place? [18:50] You can push it off into a repo somewhere else later if you want, but why not keep it simple to start? [18:51] beuno, I have bzr/project/project.stable as an initialized project on a remote machine... and i have my trunk/ in my home dir... bzr add wont work... unless it knows what repo it needs to add the files too..... at least i think [18:52] Can bzr do replacement of variables such as $Revision$ and like SVN? [18:53] gotgenes: Keyword substitution. No. [18:55] fullermd: :-( Is it a planned feature? [18:55] somewhat [18:55] its a bit contentious, have a look at bzr version0info though which may do what you want [18:55] Alien_Freak: 'bzr init; bzradd; bzr commit' [18:56] Alien_Freak, it adds it to the directory you are currently in recursively [18:56] Alien_Freak: we have a getting started guide you might find useful [18:56] as fullermd pointed out, it's probably best for you to create it locally and then push it [18:57] yah,.. i probably should look into that...the whole branching tidbit.. is confusing me somewhat [19:02] Alien_Freak: http://doc.bazaar-vcs.org/bzr.dev/en/mini-tutorial/index.html [19:06] is there a book on bzr yet? just curious.. [19:12] thanks poolie_. [19:24] jam-laptop: so does that strawman work for you ? [19:24] lifeless: well, you didn't respond to my comments [19:24]