[00:01] working adsl FTW === lifeless_ is now known as lifeless [00:06] Are there instructions on how to add bzr to the SCM in XCode? [00:16] spiv, thanks for your mail to sg [00:27] Zectbumo, not that i know of [00:27] i believe there are some people who do use it there though [00:27] a post to the list may shake them out [00:27] where is the list? [00:27] bazaar@lists.ubuntu.com [00:27] or you could post where you're got up to in adding it [00:28] thanks poolie, I'll try that [00:28] lifeless: I would like to know more of this 'working adsl' of which you speak. [00:30] the electrons move [00:30] from node to node [00:30] on wires copper [00:30] like autumn leaves [00:31] in the summer time [00:31] igc: ping [00:31] the living is easy [00:31] hi lifeless [00:31] igc: do you want to talk about this plugin stuff [00:31] igc: or just rapid fire emails ? [00:32] as in auto-loading of plugins? [00:32] I'm yet to look at it to be honest [00:32] as in I b:rejected your patch - you may not have seen that [00:32] ah - no I hadn't seen that [00:32] * igc looks [00:33] lifeless, are you in need of relief from skull drills? [00:33] poolie: no drilling so far today [00:33] poolie: if it starts up I'll ring you and run for a train [00:33] igc: you seem to be reimplementing bzr 0.8's hook system, which is sad. [00:33] igc: so I'd like to understand what you want to achieve, and hopefully suggest a smaller way to do it. [00:34] lifeless: fire away [00:34] uhm, you're the one with a mission in this area:) how about you describe what you want to achieve [00:35] lifeless: I want an easy, scalable way of configuring command line scripts as hooks ... [00:35] a few people have rejected Bazaar for Hg on this feature alone [00:36] igc: Ok. I think this is a rather restrictive and difficult to work with medium, so don't want our core to get cluttered; we can do this entirely as a plugin. [00:36] I don't care a lot about the Python hooks stuff because we support that already [00:36] theres a /lot/ of friction between object-model and command line [00:36] and requiring that every object model hook be command line exposed - urgk. Not to mention locking coherency and performance. [00:36] and windows. [00:37] * Toksyury1l wonders absently if there are any plans to rewrite bzr in a compiled language someday in the future === Toksyury1l is now known as Toksyuryel [00:37] Toksyuryel: python can be compiled FWIW :) [00:37] ok - so we can make it selective as to which hooks can exposed if you wish [00:37] Toksyuryel: but more seriously we have rewritten the inner loops in C already [00:37] oh, sweet ^^ [00:37] s/can/get/ [00:37] Toksyuryel: (Not all inner loops, but selected critical ones) [00:39] spiv: you seem to put success/failure before body content in replies; this doesn't work in the general case [00:39] * Toksyuryel nods "well it is nice to know that it's even being attempted ^_^ bazaar is a great system, and I think being available in a version with far less overhead would get a lot more people interested in using it :)" [00:39] lifeless: chunked replies can be interrupted with an error [00:39] python is already a compiled language [00:39] but this isn't a helpful response :) [00:39] spiv: smells like duplication to me [00:40] spiv: I would be strongly inclined to have [BODY] STATUS [00:40] So most errors would tend to always have no body, then the error status? [00:41] That seems reasonable. [00:41] well the idea I have is that pure errors have no body [00:41] my understanding is that compiling python would still lag behind something like C, and could potential introduce strange compile-time errors that interperted python wouldn't experience [00:41] HTTP's 'errors are html pages' is nasty [00:41] * Toksyuryel could be wrong about this [00:41] Right, I agree. [00:41] I was just referring to the case where an error doesn't occur until the body has already begun. [00:42] That does sound like a good simplification to me, thanks. [00:46] except in the case of http 1.0 indeterminate length replies, you can just treat a connection which closes unexpectedly as an error. [00:47] igc: reviewing your patches now [00:47] igc: I get the impression that you are cloning hg's style here or something, but it has a smell about it that is quite un-bzr-like. [00:47] igc: I appreciate that some folk may say 'we have to have shell hooks' - but lets not copy an inferior system to give them their feature. [00:48] (if hg was superior, we wouldn't be hacking on bzr ;)) [00:48] thanks lifeless. The design is meant to be better than Hg's fwiw :-) [00:48] and it is [00:48] (not saying it can't be better though) [00:48] Right now I have a pretty strong conviction that this all belongs in a plugin [00:49] the shell command wrapper stuff is probably good to put in the core once the code duplication is removed [00:49] oh, I missed another spot of duplication, the unit test support for running real sub processes. [00:49] the config stuff made me wince; I've replied to it [00:49] but only comment because I may be being conservative [00:57] igc: right the main one I've looked closely at as well. I think you got the wrong end of the problem and pulled the thread there [00:58] igc: if you instead start with adapting a config driven shell interface into the existing hook structure, with no changes to the current api (it doesn't need any) I think you'll find it works a /lot/ better and more smoothly. [00:58] (And yes, I do mean start over on the third patch - sorry) [00:58] * igc digests that [01:00] hint: If shell hooks are configured in *Config, then *Config knows the hook exists and should register it [01:02] the current precommit hook also has a performance problem [01:02] its recreating the work of the commit by calling changes_from [01:03] anyhow, I need caffeine apparently, so I'll be back in a few minutes; I'm very happy to have a voice call if you think more bandwidth will help [01:37] igc: you have mail; I'm not arguing against having shell scripts, I'm arguing against an implementation that is problematic (and makes changes to core it should not) [01:37] lifeless: understood [01:38] I'm ok with going back to [] instead of init_hook [01:38] the tricky bit I don't see ... [01:38] is how your auto-register approach can work when the set of hooks ... [01:38] is dependent on the *branch* [01:39] That's the important api change ... [01:39] get_hooks[hook_name, branch) instead of hooks[hook_name] [01:57] igc: when the branch reads its config file it can add hooks, can it not ? And clean them up when unlock() drops the lock count to 0. [01:57] igc: -> no api change needed :] [01:57] * igc thinks [01:58] Branch.hooks is branch independent, its global. [01:58] sounds ok (which is great) [01:58] We can *either* make it branch specific, which has some possible benefits, but some downsides as well. [01:58] OR we can do what I just described, which will also work well. === asak_ is now known as asak [01:59] lifeless: I'd probably prefer making it branch specific but ... [01:59] I'll try the other way if you'd prefer [02:00] as long as locations.conf overrides branch.conf ... [02:00] I'm happy enough [02:02] igc: I am not wedded to it being global (well, more precisely, Branch.hooks must stay global, but you could clone the current global hooks with a deep copy to aBranch.hooks, which is then local and can be tweaked by the branch. But I think thats a mistake due to interactions with bound branches, which is why I think singleton is better in the first place. [02:03] ok - let me get the run-shell-command patch resubmitted and I'll go with your 'stay global' approach [02:04] lifeless: thanks for the reivews btw - much appreciated [02:08] np === jam_ is now known as jam === Verterok is now known as Verterok_ [03:36] abentley: ping [03:36] lifeless: pong [03:36] abentley: is there a trivial method to apply an inventory delta to a tree: to actually do the tree rearrangements requested [03:37] Yes, WorkingTree.apply_inventory_delta [03:37] abentley: that only alters the inventory [03:38] abentley: I want to shuffle directories on disk; write file content out to new files and symlinks etc. [03:38] True, but that's all the inventory delta was meant to describe. [03:38] abentley: I know. the use case is 'I have a partially committed tree - all the content is in but not the revision id.' Now I want to extract this to disk. Hmm, perhaps export will do it [03:39] I think the best option would be to convert it to _iter_changes format, which revert uses. [03:41] what's the eta on the RC? [03:41] abentley: no need, export() will work just fine [03:41] I brain farted for a second :) [03:42] lifeless: So I've got an implementation of iter_files_bytes that reads each pack only once. [03:42] Now 50% of the time is spent reading the index to determine the build-dependencies. [03:43] abentley: cool; I guess that means its faster ? [03:44] Yes, it's faster for the checkout-from branch case when there's no accelerator tree. [03:45] But it's about half the speed of checkout using an accelerator tree. [03:45] So I'm looking for ways to reduce the cost of index lookups. [03:45] Any ideas? [03:48] paste your index using code [03:49] but in general: less trips to the index layer - better. And we need to do the next iteration of the index layer too - I have a half prepped branch working on that [03:53] http://paste.ubuntu-nl.org/54807/ [03:55] abentley: its pretty dense; I guess thats doing inventory and text in a single pass ? [03:56] abentley: or is it because its part of the refactored knit layer, which inventory and revision still use ? [03:56] not saying its bad btw [03:56] Yes, knit_kind can be "file", "inventory", "revision", "signature". [03:56] k. I'm a little confused as to what streams are, I suggst a comment or something [03:57] stream_id would be a better name; they are tuples of (file_id, version_id) [03:57] thats a component isn't it ? [03:57] so I would say component_key [03:58] 'the name of a component' [03:58] Well, they are actually the names of the desired streams, i.e. fulltexts. [03:59] fulltext_keys perhaps ? [03:59] I use key fairly consistently elsewhere when talking about a tuple of ids [03:59] Could work. [04:00] trivial note: while pending_versions: is faster than whiel(len(pending_versions) > 0: and IMO just as readable [04:00] There's currently a lot of pointless conversion between various tuple formats, so I'm not sure exactly what the inputs will be when I'm done. [04:01] one thing you could do to reduce overhead [04:01] make pending_versions a set of the native keys [04:01] that will reduce conversions [04:02] if you had per-kind build_maps that would do it. But maybe that doesn't fit further out [04:02] another alternative would be (kind, key) tuples [04:02] where key is (revision_id,) or (file_id, revision_id) [04:02] less conversion - just wrapping [04:03] one suggestion here - move requirements,update(new_requirements) out of the inner loop [04:03] instead, when you do pending_versions = new_pending [04:04] also do requirements.update(new_pending) [04:04] but otherwise that seems fine - you spider out nicely [04:04] The output is expected as (kind, file_id, revision_id), so it seemed simplest to retain that format. [04:04] so I suspect you'll be payin bisect() costs in index.py [04:04] thats something that is possibly optimisable without changing the disk format. [04:04] But your (kind, key) notion is interesting. [04:07] I see what you mean about requirements.update(). [04:07] sets are fast its unlikely to be a problem, but little bits add up :) [04:08] I'll probably see how iter_all_entries performs, but it's questionable to use that IRL. [04:08] iter_all_entries skips the bisection [04:08] and I know the bisection to be a problem [04:08] Would stink rather badly for many cases, though. [04:11] Yeah, looks like ~all of the iter_entries time is spent in the bisect code. [04:11] feel free to improve it :) but your current patch is orthogonal I think [04:13] * igc food [04:13] you won't be slower than the current code [04:13] lifeless: This would probably require me to have more than a superficial understanding of bisection... [04:13] abentley: fair enough ;) [04:23] abentley: I can describe the theory in an email if the code is too obtuse [04:24] lifeless: The bisect code is slow, but iter_all_entries is slower. [04:32] abentley: what project? bzr? [04:32] Yes, doing a checkout of Bazaar takes 8 seconds with iter_all_entries, and 5 with iter_entries. [04:32] heh [04:32] so, thats size_history issue showing up:) [04:33] a project with less deep history might see a different ratio [04:33] something like mozilla iter_entries will be faster ;) [04:36] We don't have a way of storing arbitrary metadata on revisions, right? [04:37] how does --fixes do it? [04:37] I thought it had a particular field. [04:38] lifeless: Especially mozilla with only one commit [04:39] fullermd: we do, its abused [04:39] I regret us adding it :( [04:39] abentley: well moz with one commit, iter_all will be fasster [04:39] abentley: moz with all its commits, iter_entries will be faster [04:39] Oh, we do? Hm. [04:39] Oh, gotcha. [04:39] I thought the whole point of such things was to abuse them :) [04:40] * lifeless abuses fullermd [04:40] Whip me. Beat me. Make me maintain AIX. [04:40] now thats cruelty [04:40] Ah, but if we made him rewrite AIX in Perl... [04:41] I could rewrite it in APL, and it'd probably be more comprehensible than the original... [04:41] Plus you could use the insanity defence if you happened to go on a killing spree afterward. [04:42] Did I mention that my first sysadmin job was on AIX? [04:42] * fullermd loads another magazine. [04:43] Anyway, some damn fool opened up Yet Another VCS Thread on $MAILING_LIST, and it got me thinking about the question "How do I find foo/bar/baz.c r1.1384.1.7 post-conversion". [04:44] Seems like stashing in random-metadata-slot at conversion time is the least evil answer. [04:44] fullermd: that can be one in the revision properties list, but it makes the revision object rather large :| [04:45] fullermd: if we're talking about CVS, we don't have to worry about renames, so we can use the filenames as file_ids. [04:45] You could use r1.1384.1.7 as part of the revision-id. [04:46] abentley: N files in a commit though [04:46] Urg. That would be Really Ugly(tm) when you have a few dozen files in a commit... [04:46] Okay, clearly I haven't given this enough thought. [04:47] Of course not. It involves CVS. Your mind shunts itself aside in self-defense. [04:47] Though it could be argued that CVS has only one file in each commit... [04:47] Well, yeah. But converting it that way would be a good way to ensure no project ever gets far enough to ask bzr the question... === asac_ is now known as asac [05:08] bbiab [05:34] lifeless: Okay, I looked at the bisect_multi_bytes code and it kinda made sense. What's wrong with it? [05:34] abentley: its slow [05:35] so there are two separate sets of bisection occuring [05:35] But the algorithm is suitable? [05:35] abentley: one is down at the disk level where we are finding the location of the key and reading its data (and data adjacent to it). [05:35] abentley: this bisection is completely fine AFAICT, reading the right data, and not slow. [05:35] abentley: the second set of bisection is occuring in memory [05:36] where we have a list of ranges that have been parsed [05:36] in a file like |-----------------------------| [05:36] we mark the bits we've parsed: [05:36] |+++----------+++-----+++--+--+++-------| [05:36] (for instance) - thats a file after looking up one key 2/3's up the file or so [05:37] --lsprof suggests that we're examining that map or parsed regions expensively [05:37] it may be that the map needs to be represented in memory in some better fashion [05:38] or just that the way bisect is used/how the results pan out can be improved [05:40] One option that might improve performance is if we can turn it into a coroutine. [05:40] Because I suspect it's got keys cached that we need to find on the next lookup. [05:41] Even if not, the position data could be quite useful, I'd expect. [05:41] if by key you mean the (file_id, revision_id) tuple stuff - thats should not trigger a lookup in the parsed regions, unless the key is not fully parsed [05:42] remember that a key on disk is [key, present_flag, references(pointers), byte_value] [05:42] so if I read the content for key X, I need to issue a second readv request to resolve its references into strings [05:42] I mean that when I'm building a list of dependencies, I have to call GraphIndex.iter_entries() multiple times. [05:42] right [05:42] And I assume there's no caching. [05:42] there is caching [05:43] iter_entries is slow because of the in memory data structure that represents what parts of the file we have parsed [05:44] Where is the caching? [05:44] self.bisect_nodes? [05:44] self._nodes_by_reference is part of it [05:45] sorry [05:45] _keys_by_offset [05:45] that maps a pointer to a parsed key [05:45] self._parsed_key_map is the bitmap of the parts of the file we have cached [05:47] Hmm. Would we want some kind of tree structure? [05:48] I don't know :). I'm paging this in as we speak. [05:48] mainly I want to ensure you see the bit that is a problem (in memory data structure) vs the bit that is ok (the actual IO's we perform) [05:48] it may be the structure is ok but we don't use it well [05:48] or it may be that the structure is not ok [05:48] I do see that. [05:49] cool [05:55] * abentley is off to sleep [05:59] night [07:09] Hello bzrrrrr! [07:23] hello matthew [07:41] "bzr: ERROR: bzrlib.errors.BzrCheckError: Internal check failed: file u'/etc/resolv.conf' entered as kind 'file' id 'resolv.conf-20071108133634-j0pcs1k03mehwsbd-106', now of kind 'symlink'" [07:42] what's the rationale for having an error for that instead of just versioning the change? [08:20] New bug: #189182 in bzr-hg "unexpected keyword argument 'find_ghosts' in hg-0.9.5" [Undecided,New] https://launchpad.net/bugs/189182 [08:51] bob2, you shouldn't be seeing that, we're meant to fix it at another level [08:51] unless you're using a very old bzr? [08:55] gotta be old bzr I would have though [09:15] hy all [09:18] anyone may help, i have bazaar installed on my laptop and my desktop , i'm tried to push the repo i have on my laptop into my desktop bazaar repo using bzr+ssh command but i fail, any clues ? [09:23] .bzr.log is a good place to look for clues [09:24] on both sides rolly ? === weigon__ is now known as weigon [09:25] on the remote side, sure. If you are successfully establishing an ssh connection [09:26] let's see if this file exists ;) [09:26] "but i fail" doesn't say much about your problem, so I can't say [09:28] the ssh connection succeed, but the bzr smart server says something about permissions [09:29] bzr push bzr+ssh://username@myhostname/Projet, error : Generic bzr smart protocol error: Permission denied: "/Projet": [Errno 13] Permission denied: '/Projet' [09:29] the Projet dir is in my home on the desktop [09:30] and when i take a look at the /var/log/secure, i can see, the successfull ssh connection [09:31] xinity_mbp: /Project is to the root of your filesystem, you logging in as root ? [09:31] nop weigon [09:32] the Projet dir is in ~username dir [09:32] wich means ~username/Projet [09:32] i found this on .bzr.log [09:32] the "permission denied" smells like it tries to access /Projet instead of ~username/Project [09:33] you need to put the full path in there [09:33] bzr+ssh://username@myhostname/home/username/Projet or whatever it may be [09:33] http://cl1p.net/xinity_bzr/ [09:34] ah better now :) [09:35] I love bzr, even when it crashes :D It's so easy to tell what's wrong [09:37] rolly: you love in practice Python. Most Python programs show this attribute: "Easy to debug" ;) [09:39] yeah it's true [09:39] seems to be working , here is my last log : [09:39] I have 0 python experience and I was able to patch a bzr module [09:40] rolly: And now you need to be a selfemployed contractor for Germans biggest mail portal, and you can charge premium prices for patching (complex and hard Python) modules without understanding them :-P [09:42] Well, I can certainly provide the lack of understanding [09:43] Oh, sorry, was an complete non appropiate assocation that I had. [09:44] But this guy managed to sit around for more than 2 months, and providing exactly 3 1-line changes replacing constants, as a contractor. That's upmanship. [09:44] those must have been some pretty important 3 lines :p [09:45] (for him to charge premium) [09:45] xinity_mbp: I think a newer client version would have reported that error properly. [09:45] anyways, past my bedtime. Goodnight all [09:46] (or perhaps a newer client *and* server version) [09:46] Using fetch logic to copy between RemoteRepository(bzr+ssh://xinity@myhostname/home/xinity/Projet/.bzr/)(remote) and KnitPackRepository('file:///Volumes/Home/Users/xinity/Documents/Exploitation/Projet/.bzr/repository/') [09:46] here is the last log i have [10:05] ok seems to be working, a last thing i didn't catch [10:06] bzr branch Exploitation bzr+ssh://xinity@myhostname/home/xinity/Projet/Exploitation send the .bzr dir , but not all the files, did i missed something ? [10:07] That's expected. "bzr branch" only builds working trees for local branches. [10:07] But if you're just sharing the branch with other people, that doesn't matter. You can "bzr branch" and so on with just the .bzr directory. [10:12] ok so how to pull the whole tree to the remote instance ? [10:13] dato:Hi! [10:14] yes? [10:15] I try to use you VimEditorIntegration plugin and found out then they do not work on Vim 7.1 [10:16] cvv: showing the diff no longer works with recent bzrs. maybe you want to try `bzr ci --show-diff` [10:18] What do you mean? bzr diff work perfectly in bzr 1.0 [10:19] cvv: what does not work for you in 7.1? [10:20] I do not see diff. in both panel same text but `bzr diff` tell about more differencies [10:21] cvv: try running `bzr commit --show-diff` [10:22] bzr: ERROR: no such option: --show-diff [10:23] ok [10:23] then it's not that [10:23] well [10:23] er, probably is [10:23] I never use option --show-diff in past [10:23] it's a bit new [10:24] dato: "bzr diff" [10:24] cvv: so, if you do `bzr commit`, and the editor starts, and you go to another terminal, and you do `bzr diff` there, do you get an error about the repository being locked? [10:24] dato: you should not. [10:25] Qhestion: of course you should [10:25] no. [10:25] diff is a readonly task, commit is a readwrite task. [10:25] but there is a handling for that [10:25] Qhestion: sorry, but the facts support me [10:26] (unless the behavior was changed in bzr.dev in the last two days) [10:26] ok right [10:26] you can't diff while committing [10:26] ok you are right. [10:29] bzr diff [10:29] bzr: ERROR: Could not acquire lock [Errno 11] Resource temporarily unavailable [10:30] cvv: right. you need bzr 0.91 or newer to be able to see the diff in the editor, I'm afraid. [10:30] I just commited files, where were they commited to? Is everything contained in the same project directory? [10:31] Coke: try "bzr info" [10:32] Ok. I at now will be upgrade to bzr-1.0 [10:32] spiv: so everything is a branch? [10:33] Coke: I'm not sure what you mean by "everything" :) [10:33] spiv: every repository [10:33] No, in bzr we use "repository" to mean something different to a "branch". [10:33] spiv: what would be considered a "local copy" [10:34] A repository is where the revisions of one or more branches are stored. [10:34] (Often a repository is co-located with a branch, and so holds just data for that branch) [10:34] spiv: ah, if we are several networked developers working on the same project we have a central repository and we each have our own private branch? [10:35] cvv: good. in that case, you just use `bzr commit --show-diff` [10:35] Well, it's usually easiest to ignore repostories. [10:35] spiv: good. [10:35] The things you work with are branches most of the time. [10:35] (Or perhaps a checkout of a branch) [10:36] spiv: so, each developer has a branch and then there's a branch at our project server too? [10:36] So when you do "bzr commit" it creates a new revision on that branch. [10:37] You can work like that. You can also have just one branch, and have each developer just have a checkout of that branch. [10:37] (i.e. very similar to how you'd use SVN or CVS) [10:38] spiv: ok. what's the difference between a checkout and a branch? [10:38] A checkout is also called a "working tree". [10:38] So it's the files on disk that you work with. [10:38] A branch is a line of development. A series of revisions. [10:39] spiv: ok, then I guess it works sort of the same way like SVN in that respect [10:39] my oh my i'm lost :( [10:39] So if you have a checkout of a branch, and someone else commits to the branch, then your checkout would be out-of-date. [10:39] So you wouldn't be able to commit to that branch with that checkout until you did a "bzr update". [10:39] Argh! There's no bash autocompletion for bzr yet! [10:40] spiv: ah, just tested checking out. ok. it's very similar to cvs [10:40] (Although you would still be able to make "local commits") [10:40] If you're coming from cvs or svn, using checkouts is a pretty good way to ease into bzr. [10:41] Most people using bazaar get addicted to making branches though :) [10:41] spiv: yes. it does seem tempting. [10:41] Often a good way of working is to make a new branch for every distinct feature you're developing. [10:42] spiv: different thinking [10:42] spiv: branching and merging is a pain in the ass with CVS and SVN [10:42] Exactly. [10:48] sounds weird , i followed the pdf doc to build a central repo [10:48] when i do a bzr ls bzr+ssh.... it shows a list of files [10:49] but when i connect remotely, i can't see those files [10:49] spiv: if I work on my branch and change files, can I revert or is the branch "hot"? [10:50] xinity_mbp: 'bzr ls' lists files that are versioned, not what is actually on the filesystem. [10:50] spiv: lemme rephrase that. :) are the changes stored in each branch? [10:50] Coke: yes, each branch keeps a full history [10:50] this is very confusing for xchat having someone else called mbp :) [10:51] spiv: so I can relax and work on my branch (which happens to be the branch root location) and not worry about not being able to revert certain changes? [10:51] Coke: if you have the bzr-gtk plugin installed, "bzr viz" does a great job of showing you the history in a pretty way [10:52] spiv: I hate pretty! [10:52] :) [10:52] Odd_Bloke: how to send those files to the remote repo ? [10:52] xinity_mbp: you could install the "push-and-update" plugin [10:53] spiv: let's try then ;) [10:53] Coke: I don't quite understand your concern. Perhaps you should clarify what you mean by "revert"? [10:53] Coke: There's a "bzr revert" command, but I'm not sure if has the same meaning as what you want or not. [10:53] spiv: I edit file and save, oops! made a mistake, can't remember what I've changed, go back to last commited revision [10:54] spiv: no, more like "revert" in the english sense [10:54] spiv: in svn I'd just remove the changed file and run svn update [10:54] "bzr revert the_file" will revert it to the last committed revision. [10:54] spiv: is it doable for the entire branch, including subdirectories? [10:54] (and "bzr revert" will revert the entire working tree) [10:54] spiv: ah [10:54] Well... I'm all good now. [10:55] xinity_mbp: The files are already there, in version control. The only reason they aren't on the filesystem is that they haven't been checked out. [10:55] There's just one more thing, where can I get free project hosting that use bzr instead of svn? [10:55] Coke: revert changes the working tree, not the branch, btw. [10:55] Coke: Launchpad. [10:55] spiv: my branch is my working tree. :) [10:56] Odd_Bloke: sorry for my noob attitude , should i do a checkout on the remote side ? [10:56] xinity_mbp: Yeah. That's what the push-and-update plugin does for you. :) [10:56] Odd_Bloke: thanks. [10:56] Odd_Bloke: cool ;) [10:57] Odd_Bloke: I don't get it, is that an URL? [10:57] ah, .net, of course. It's a network, not an .org. [10:57] Coke: you can host bzr branches on anything that supports sftp and http [10:58] Coke: Your branch and your working tree are conceptually different. The branch is to do with history, whereas your working tree is just whatever files happen to be in the directory you're using bzr to manage. [10:58] (or ssh) [10:58] luks: that's what I will do with the projects at work, but I have a few things hosted on SF.net [10:58]