[00:09] lifeless: fyi, http://paste.ubuntu.com/3387/ [00:10] lifeless: local operations on that tree is now working well performance wise btw. thanks [00:13] asac: cool [00:16] lifeless: yeah ... but 25min is too long ... the 81M should be much faster. but maybe that lp === mw is now known as mw|out [00:18] lifeless: wow ... i tried https://code. ... it just took 6 minutes. thats fair. so maybe it was indeed lp ssh server slowness [00:19] asac: its in pack format now ? [00:19] i used just bzr init with 1.1.0.dev.0 [00:20] bzr info says: Standalone tree (format: pack-0.92) [00:20] yah [00:51] New bug: #181391 in bzr "model 1 to 2 conversion breaks revision sha1 validator" [High,Triaged] https://launchpad.net/bugs/181391 [01:30] poolie: I'm off to buy groceries bbiab. [01:31] k === cprov is now known as cprov-ZzZ [02:02] lifeless: Now that PPA supports Dapper, Edgy and Feisty, do you have any plans to move the bazaar-vcs.org debian repo to PPA or would you rather keep it separate because of the signing? [02:38] jelmer, i'd kind of like to do it in PPA, i think Robert has unresolved objections [02:38] mainly that it's not signed, and cannot build on non-intel architectures (which we don't build now anyhow) [02:38] iirc [02:38] oh, also that there's more latency [03:33] I'm trying to 'rm' a file, and 'mv' another file into its place, as part of a single revision === bignose_ is now known as bignose [03:33] 'bzr rm foo' [03:33] 'bzr mv bar foo' [03:34] result: "Could not move bar => foo: foo is already versioned." [03:34] but this is conceptually part of a single change. how can I achieve it without separate commits? [03:36] bignose: works for me. What version of bzr do you have? [03:37] Bazaar (bzr) 1.0.0 [03:38] Hmm. I'm using bzr.dev. [03:39] bignose: works for me with 0.92 too. [03:40] ahhh. I'm in a 'bzr shell' [03:40] bignose: I see this result: http://rafb.net/p/rnDFwP86.html [03:40] experimentation shows that 'rm' in the shell **doesn't* invoke 'bzr rm' [03:41] why would that be? [03:41] bignose: I think "rm" in the shell executes /usr/bin/rm [03:42] (or rather /bin/rm...) [03:43] bignose: it appears "bzr shell" from bzrtools special cases "rm" and "ls" to always use the system version rather than the bzr command. [03:44] spiv: thanks. it's annoying, but I can at least see the reason now. [04:15] poolie: and that we can't poke and tweak it; its behind an automation barrier as opposed to an admin barrier === asac_ is now known as asac [07:27] poolie: would it be fair to say that you are the Designer of bazaar? [07:33] because there's a message on http://thyrsus.com/lists/uvc-reviewers/2008-January somewhere [07:33] that says that 'the designer of bzr was an Arch hacker' which is not really true as far as I know [07:34] I'll find the exact url if you like [07:34] lifeless: ^ also [07:34] is that a leading question? [07:35] uvc ? [07:35] anyhow, thats bogus [07:35] er maybe [07:35] esr's attempt to write a guide and history to version control systems [07:35] martin architected the overall initial design 2 years ago based on a review of arch/monotone/svn/cvs/some others [07:35] bogus - that's what I though [07:36] that's what I understood. and esr should have been able to go over the sourcefrog blogs perfectly well on his own [07:36] bzr's current design only has a little resemblance to that first design, though the design -goals- have not changed. [07:36] nod also [07:37] I was an Arch hacker; and I've had some influence on the design, as have Aaron Bentley and many others [07:37] yes, and that's where I persume they get tat imperssion [07:37] I would label Martin Architect, not designer, to me it carries a less solitary-load-bearing-sole-responsibility thing [07:37] but he has an obligation to write history acrruately if at all [07:38] yeah architect, .. that's why I wrote Designer with a captial D :-) [07:39] perhaps it's a nice goal to draw a narrative out of the histoy, but he(inevitably?) over simplifies [07:46] Here's the link: http://thyrsus.com/lists/uvc-reviewers/2008-January/000023.html [07:46] quote: bzr -- Designed and written by a former Arch hacker. [07:47] he's been taken to task for the other bits in that message but not that one [07:47] I can folloow up if you don't care too [07:47] bzr has been written by a great many people. [07:48] oh I'mm well aware of the history of bzr. [07:49] reading esr and -t's messages gived me indigestion [07:50] * mlh feels woozy - decides to go home [07:50] Glancing at the commit history, it doesn't look like that will be a very interesting book. I'm sure it will be widely read, though {sigh}. [08:03] Fwiw, I think bzr's history a bit interesting but its future far more so. :) I may seem a bit overzealous, but I expect it will become king among the free VCS out there at some point. [08:03] It just doesn't get in my way very often at all... [08:21] I sure would like to insert it into a place or two... [08:35] fullermd: Was that to me or AfC? [08:38] mlh: please follow up [08:44] To your general thrust (though I rather doubt bzr will become king, or that there will be a king) [08:56] Hi all [08:57] What's the current recommended storage format for bzr if I want to use bzr-svn? [08:57] Hehehe, well, I hesitated looking for a better word than "king," but I mean in the sense of being most widely preferred. [08:59] Yeah, I'm just not sure there will be one. I'm pretty much certain there will never again be a VCS that owned the market like CVS did. I'm not sure there will ever be any majority system. [09:08] Hi. I have a problem with bzr but maybe it is just me (and not bzr) [09:09] from last time I used it the "bundle" command disappeared and "send" doesn't produce anything. [09:09] i think you can say send -o output.bundle can't you? [09:09] * mwhudson checks [09:09] I'd like to get the last n revisions and bundle them but while "patch -rX" works, "send -rX" doesn't produce anything [09:09] just a header [09:10] fog: yes, looks like it [09:10] mwhudson: yes, I tried send but it outputs just the header. [09:11] I can use diff (sorry, not patch) and produce a meaningful output but I can't put the same diff in a bundle using send. [09:11] :/ [09:14] so, how can I use send to produce the "same content" of diff, but in a bundle? [09:16] fog: try "bzr send -r X..-1" [09:17] that will bundle the sequence of revisions from X to -1 (the head revision) [09:17] or "bzr bundle -r X..-1" even [09:19] ah.. it works. [09:21] jamesh: the help text about "-r" says to see revisionspec but revisionspec doesn't talk about "..". should't be better if the help explained that some commands take a range of revisions? [09:21] jamesh: btw, many thanks. [09:22] Hi. A while ago, I exported my svn repo and used it as the start of a bzr branch, which I've been committing to. Now I want my svn history. [09:22] fog: that sounds like a bug [09:22] I have successfully created a new bzr branch with all the svn history. How do I take all the revisions from my original bzr branch and append them to my new bzr branch? [09:23] astraw: perhaps try the bzr rebase plugin [09:24] it will let you apply a sequence of changes to an unrelated branch [09:24] jamesh - thanks, that looks like what i want. i knew there had to be a way. [09:35] hmm, rebase is giving me: "bzr: ERROR: Repository KnitRepository('file:///repo-with-recent-changes/.bzr/repository/') is not compatible with repository KnitRepository('file:///repo-newly-created-with-svn-history/.bzr/repository/')" [09:36] This is the outcome of running: bzr rebase --dry-run /repo-newly-created-with-svn-history [09:36] from the repo-with-recent-changes branch [09:39] astraw: what are the types of the two branches as reported by "bzr info"? [09:40] jamesh: Standalone tree (format: dirstate) and Standalone tree (format: rich-root) [09:41] (repo-newly-created-with-svn-history is the rich-root) [09:41] so the dirstate one is the old branch with your changes in it? [09:41] yes. [09:41] mwhudson, jamesh: thank you for the help. cu. [09:42] fog/jamesh: 'bzr help revisionspec' includes an example using '..' but, as fog says, does not actually discuss '..' directly. [09:42] astraw: I'd take a copy of the branch and run "bzr upgrade --format=rich-root" on it. [09:42] dlee: yes, I've seen the example after jamesh told me about .. :) [09:42] astraw: use the copy as the source for the rebase [09:42] dlee: but I missed it the first time. it is buried quite deep. [09:43] Is rich-root-pack still considered experimental in 1.1? [09:43] anyway go to go. thanks again. [09:46] Lo-lan-do: seems to be, still. a patch went in recently to mark pack-0.92 as non-experimental (!!!), so... [09:47] so it should be marked as non-experimental as well, given that rich-root is not experimental itself [09:47] Lo-lan-do: thanks for bringing up [09:48] I'm about to start a new repository, and since it's going to interact with SVN, I'm pondering about the best format. [09:49] A bzr branch from the SVN repo gives me a rich-root format, currently (1.0) [09:49] I'd like to switch to a packed format, but only if it's reasonable :-) [09:49] rich-root-pack is very reasonable :) [09:50] Cool. I'll upgrade as soon as the branching is done then. Thanks. [10:01] how do I specify a "merge base revision" with rebase? [10:14] I've been sticking to pack-0.92 because I thought all newer stuff was experimental. I use bzr 1.0 and nothing older for projects I'm starting or transferring into it. Should I switch now to something else for any reason (I know bzr-svn needs rich-root, but other than that...)? I need not to risk data loss or problems my would-be Bazaar collaboraters could hit with newer formats, [10:14] but if it's safe to use something newer already, it could save me a lot of upgrades later. [10:15] I don't know what the -subtree variants of formats are either... I keep mixing that up with nested-tree, for which I wait anxiously. :) [10:16] From what I understood, the -subtree variants has been replaced by rich-root [10:18] -subtree is the format of the repository needed for the nested-tree functionality. as it is regarded as experimental, rich-root was created, which is afaik a very small (and safe) subset of -subtree, and it's enough for bzr-svn's purposes. [10:18] dlee, Lo-lan-do ^ [10:18] Lo-lan-do: I thought there was a rich-root-subtree, but I'm probably wrong; it's not listed in 'bzr help formats' (1.0) anyway. [10:19] Nested trees aren't implemented yet, right? [10:19] dlee: also, if you are not using bzr-svn, pack-0.92 should be enough for you, and afaik rich-root-pack would give you nothing (but if you fear upgrades, you could anyway upgrade) [10:19] Lo-lan-do: "work in progress TM" afaik [10:19] 'kay [10:21] dato: I'm setting up (hopefully) to convert about 40 projects at work into Bazaar (if I can get everyone to use Bazaar), so this is more about picking a format to start with as part of that process. [10:22] I think I am to where I just need to deal with a line ending issue (I discussed that in here last night I think), then the conversion process will be ready to test on a fairly large scale... [10:24] i'm missing something obvious. trying to do a bzr rspush to 'deploy@biggecko:/home/deploy/bzr/atelier-main'. i can login into ssh via deploy@biggecko just find, and the bzr directory is there already. what am i missing? === cprov-ZzZ is now known as cprov [10:52] AfC: markdown is pretty cool [10:56] I've never managed to get my interest piqued by any of that class of formats :| === mrevell is now known as mrevell-lunch === mrevell is now known as mrevell-lunch [12:20] dato: it's lovely to work in [12:21] One can, of course, use anything ... including raw HTML for that matter; [12:22] the point I was trying to encourage is that the front side web site can and should be in version control [12:22] (ideally right alongside your source code, but that's up to you; but it works out nice when doc/* is right in the sources and in the website both) [12:23] thus allowing the thing to be static or nearly so (thereby allowing things like Expire headers to be sent properly) [12:23] not to mention WAY faster [12:23] (wikis are always terribly slow for some reason) [12:23] (and Bazaar's website is terrible in this regard) [12:24] ... but I like Markdown because it is so unobtrusive; [12:25] *especially* because it means the documentation can be nice 80 or so character wide text files readable in a terminal with less right there in your source tree; [12:25] or rendered to HTML for the pretty factor online. [12:26] It's all about having your cake and eating it too :) [12:26] anyhow, if ReST is used elsewhere for bazaar documentation, I doubt another markup format would be adopted [12:26] dato: very likely. [12:26] dato: find ReST to be unnecessarily overweight, but that's a side issue [12:27] dato: the main point was getting text based doc sources to drive the website but be in the source code or very near it [12:28] (thereby allowing patches, review, etc but most of all a flow of information that allows anyone to contribute but still allows a measure of consistency and refinement) [12:29] [The part I love is that your entire website can be a single 404 page: ask for BzrVsGit.html and, not finding such a page, the 404 handler checks to see if BzrVsGit.txt exists. It does, so it renders it. Done. Ta-da. [12:29] (and you can cache if you like by writing BzrVsGit.html, but that's not necessary) === mrevell-lunch is now known as mrevell [12:43] AfC: Achitecturally, I see little difference between Moin-markup-in-moin-vcs and Markdown-in-Bazaar. [12:47] abentley: the difference is that you access the whatever-in-$VCS directly, and the same [review and approval] paths apply. [12:48] You can edit text files properly and then submit changes as patches, instead of working in random edits through some cumbersome web-app front end that has no quality control [12:50] I don't think that's an improvement. [12:50] I like the instant feedback of vcses. [12:50] Of wikis, I should say. [12:50] And the same people who review code also keep a close eye on the wiki. [12:51] The pages that are coming in for the most criticism at the moment are BzrVsHg and BzrVsGit, and both were written by Ian, with tweaks from myself and others. [12:53] abentley: well, you and I disagreeing about fundamentals is nothing new [12:54] abentley: but the quality problems with the Bazaar website far far exceed those two pages. [12:55] both in terms of content and performance. [12:56] Hi again. Can I disable a plugin for just one invocation of bzr? With a CLI parameter maybe? [12:56] not only one afaik [12:56] Lo-lan-do: bzr --no-plugins [12:57] Hm. It'll do. Thanks :-) [12:57] 'night all [12:58] Is it possible to store that in a branch-specific config file? [12:58] Lo-lan-do: no [12:58] Why do you want that? [12:58] Actually, in a lightweight-checkout-specific would be even better. But I'll manage. [12:59] I have a bzr branch inside which I did an svn checkout of a subdirectory (debian/). [12:59] bzr commit debian/changelog complains that an assertion has failed, presumably because the svn checkout isn't rooted at the same point as the whole bzr branch. [13:00] Ignoring the bzr-svn plugin for operations seems to fix the problem for me. I can live with --no-plugins :-) [13:01] But if there's a better way, by all means tell me about it :-) [13:01] This sounds a lot like a bug in bzr-svn. It should just try to commit to the svn repo. [13:01] I don't want it to. I'm doing a one-way gateway. [13:02] Yeah, but there definitely shouldn't be assertion failures. [13:02] Maybe there should also be a way to flag an svn checkout so that bzr ignores it. [13:05] Anyhow, if you could report the assertion failure against bzr and bzr-svn, that would be helpful. We can sort out where the bug actually lies. [13:05] Will do [13:07] I think causing .svn directories to be ignored is a bzr-svn issue, because presumably you'd need some metadata in the .svn directory to do that. [13:07] But you can also control your plugins by setting your plugin directory. [13:08] If you set the BZR_PLUGIN_PATH environment variable to a directory that doesn't contain bzr-svn, that should also disable it. [13:33] Any way to push a conflicting (locally moved via --force) tag? [13:34] --overwrite [13:36] The help for that looks dangerous... does that also erase stuff others might have pushed to the same repo? [13:36] it does not erase anything in the repository [13:38] but it does overwrite the branch history in case they are diverged [13:40] I'm having trouble understanding the difference between overwriting history and erasing info (by overwriting it) in the repo. [13:41] repository is a storage for revision data, branch is a pointer to a revision in the repository [13:41] so if your remove branch is on rev2, and you are pushing branch that is on rev1 with --overwrite it will set the pointer to rev1 [13:42] but rev2 is still in the repository [13:42] as far as I know, none of the current formats will remove any data from the repository on push [13:43] it's similar to uncommit locally, where you also only change the pointer [13:43] Hmm... I thought uncommit removed data also. [13:43] no [13:44] So I commit rev 320, uncommit it, and commit again. I'll get a new 320 but have both 320's in the repo somehow, with one being inaccessible?? [13:45] (Disclosure: I've not used uncommit :) [13:45] right [13:45] using revnos makes sense only in context of a branch [13:45] but yes [13:45] Does anything then provide access to, or show, the first r320? [13:45] -r revid: [13:45] Ah... you'd probably need the revision ID... [13:46] right [13:46] but without pulling it directly like that, you'd never see it again. [13:46] yep [13:47] unless somebody else pulled/merged the branch before uncommitting [13:47] but you probably won't use uncommit on a public branch [13:47] Makes sense... now just trying to figure out what could be messed up if I push a tag move while others are pushing stuff up to the same repo... [13:47] true [13:47] to the same branch or repository? [13:48] branch [13:48] well, in any case, nothing [13:48] because push requires a lock [13:48] hehe [13:48] Actually... are branch, repo, and shared repo all three different things? I know what a shared repo is pretty clearly. [13:48] bzr push complains about conflicting tags and not diverged branches, --overwrite should be quite safe thing to do [13:49] there is no technical difference between repo and shared repo [13:49] yes, but that makes non-atomic the whole process: push, get a tag conflict but not a diverge notice, push again but discover someone else just pushed inbetween... [13:50] hm, right [13:50] I wonder if we should have a way to --force just tag settings? Not fully thought out... [13:51] I actually thought earlier about whether anyone would have a use for a strictly local type of tag that does not push, but again, not thought out. [14:07] hi *, I have a problem with bundle/merge without a central repository: [14:07] machine A initialize and repo and commit revno 1 [14:08] machine B branch from machine A at revno 1 [14:08] machine A gets 2 more commits (revno go to 3) [14:08] then we are disconnected and I want to pass changes 1..3 from A to B using a bundle [14:08] on A: bzr bundle -r1..3 [14:09] on B: bzr merge thebundle [14:09] at this point merge fails and says that revision XXX (it is the id of revno 3 on A) can't be found in B [14:09] log on B show the correct id for revno 1 on A [14:10] so, why do it fails? [14:11] seems to me that B has evenrything needed to do the merge [14:11] there is something that I am missing? [14:12] as a bit of extra context, the resulting bundle appears to assume that the recipient has all the revisions passed in the revision spec [14:14] I am pretty sure that "bzr bundle-revisions -r X..Y ." used to produce a usable bundle for for a branch containing X [14:19] looking at the help text, I think it is a regression [14:30] the bundle probably does not include the revisions because the submit branch does contain them [14:31] dato: the bundle does not contain the bundle (but it contains the diff!) [14:32] I just did a test and if I branch locally at -r1 and then pass that as the argument, the bundle is correct [14:32] yep [14:32] let suppose my original branch is in XXX [14:32] bzr branch XXX -r 1 XXX.ouch [14:32] cd XXX [14:32] bzr bundle -r1..3 -> does not work [14:33] bzr bundle -r1..3 ../XXX.ouch -> works [14:33] (personally I believe that whenever -r is specified, those revisions ought to be included in the bundle metadata no matter what, but maybe abentley has a good reason why it shouldn't be like that) [14:33] abentley: ^ [14:33] fog: correct [14:34] dato: ok, but ... why? I feel extremely stupid here and I just don't understand why I need an "extra" branch to generate the bundle. [14:35] fog: abentley would be the person with the canonical answers here. the idea is that you generate a bundle in order to apply it to some target branch (the "submit branch"), and not as a means of arbitrarily bundling up revisions from the repository [14:35] personally, what I said above about -r being specified, but I cannot do more, I'm afraid [14:35] dato: ok, so the new question is "how do I arbitrarily bundle up revisions from the repository"? [14:36] because creating a new branch every time I want to send something to a collegue is inelegant (it is cheap, ok) [14:38] you shouldn't need an extra branch, you should already *have* an extra branch :) [14:38] I'm not sure exactly of your use case here, but generally, if you're developing each feature or bugfix (or whatever concrete change) in its own branch, then things work out nicely [14:39] radix: why should I have the branch my colleague is working on? [14:39] fog: how do you know which revisions you have to send? [14:39] I don't know what you mean by that [14:40] fog: I often keep copies of branches I need to access when offline [14:41] fog: given the setup you described, you are effectively offline from your colleague so it could be useful to have a local mirror [14:41] (for more than just this case, which I consider a bug) [14:43] dato: we keep in touch by email and usually is just the last one. [14:43] jamesh: yes; I think this is the best approach [14:44] dato: it is something like "I fixed this bug, merge now istead of tomorrow when we're togheter at the office" [14:44] fog: *personally* I'd just publish my branch somewhere, and have them pull from there. maybe in a private server over sftp if the code is not public. [14:45] food time, bbl [14:46] anyway, I understand why it works that way. [14:46] thank you everybody. [14:51] dlee: yeah, pack-0.92 would be the best choice. I think it's also the default now [14:54] Hi jelmer [14:56] hey Lo-lan-do [14:56] I suppose you've seen my latest bug reports? :-) [14:58] There's no hurry, really, I just didn't want to forget about them. [14:59] yup [14:59] the first one's already closed [15:04] jamesh, dato: ok, everything is working. thanks again. === mw|out is now known as mw [15:11] jelmer: thanks [15:20] New bug: #181520 in bzr "bzr log FILE don't show revisions where file was removed" [Undecided,New] https://launchpad.net/bugs/181520 [15:28] Verification of my understanding of where nested-trees are going: If I now (in pack-092) create a branch "proj" that contains subdirs "proj/a" and "proj/b," can I (when nested-tree comes out) upgrade my branch and then do something like "bzr co (path)/proj/a" to get just the "a" part in its own branch? [15:29] Planning project layouts here... [15:37] dlee: that's partial checkouts [15:38] dlee: nested trees would be the ability to add one branch to another other or "upgrade" a directory in a branch to a branch [16:02] What's the status of partial checkouts then? [16:03] don't think there's anybody working on them at the moment [16:04] Scenario (hopefully not summarized beyond comprehensibility): We do development in an environment where it is sometimes advantageous to have a "live" checkout--one in a directory of files managed (or partly managed) by a running program. To do this requires that there be no directory names/levels above the files: [16:06] In my example, I would need .bzr to be in the folder with the files. It's fine to check it out as "a," but then I'd move the files and .bzr to where the live system is. We do this so the VCS can catch changes made from GUI screens to config files etc. among other reasons. [16:06] CVS and Svn support this, though maybe not by design so much as happenstance. [16:07] you may be able to work around it a bit using nested trees, but what you really what (as I understand it) is support for partial checkouts [16:08] probably best to bring it up on the mailing list, I'm not sure what the plans in this area are [16:08] dlee: so proj/a and proj/b really belong in the same branch? [16:09] So a determining question: If my branch is (as above) proj with proj/a, proj/b, etc., is there now (or do you think there soon will be) a way for me to arrange that "bzr commit ..." can be issued from a dir containing proj/a's files but without requring that the folder be named something/a or proj/a? [16:10] We do work for many companies, and the standard here is to make (in CVS now) a dir for each company. Most of those are just one project, but some contain several. [16:12] Often, the code for different projects for one company *are* related or share common components. We do accessibility work, and the code is mostly scripts for a product called JAWS (http://www.freedomscientific.com). [16:16] dlee: I don't think there is a way to do that at the moment [16:16] dlee: There will be a way to do that with nested trees because you could make each company's directory a separate branch [16:16] I figured that, but I also figured it was soon coming... looks like I may have to rethink a couple plans. :) [16:17] the code is there, but it's still experimental [16:17] and a couple of tests for it are still broken [16:17] s/broken/not passing/ [16:18] I'm not sure how much it is to get those to pass [16:18] LarstiQ: ping [16:18] Sample structure, each dir of which should allow checkout: co1 (one proj so no subdivision), co2, co3, co3/a, co3/b ... (co3 AND co3/a and co3/b should be checkoutable if possible) [16:19] If not checkoutable, as I said, at least we'd want a way to go "cd co3/b; mv * (including .bzr) (live path); cd (live path); (work on stuff); bzr commit ..." [16:20] I'll need to assess how many people besides me really do this I guess. :) It may be mostly me... [17:19] I want to version my various system config files, but i imagine making a repository at the root would not be advised, correct? [17:26] I don't see a problem with that if you don't do 'bzr add' and scan the entire filesystem into your repo. :) But I'm assuming things like "bzr commit" (without filenames) will *not* scan the whole fs... I think I'll experiment with this myself. [17:26] dlee: doesn't it search the whole fs when you do a status/commit though? [17:27] for unknown/unversioned files? [17:29] I'm new enough to Bazaar not to be sure of this yet... but I do get an error on 'bzr init' in / [17:29] did you run as superuser? :P [17:29] i think it'll scan everything though, i wouldn't try it :) [17:30] Yes, and I got this on bzr init: bzr: ERROR: Transport error: rrno 21] Is a directory: '/' rrno 21] Is a directory: '/' [17:31] haha, wow [17:31] sounds like a bug [17:31] i don't think anyone expected anyone to do that :P [17:31] I have a small FreeBSD system here; if it scans the whole box, all that happens is my mail gets slow :) [17:32] ah, okay then :p [17:34] Workaround: cd /tmp; bzr init; mv .bzr .. [17:34] I'll probably file a bug on the above error, though I doubt a lot of people are inconvenienced by this one. Certainly a corner case :) [17:34] i'd say :p [17:35] To your original question: All else I'd say is to watch those perms... you pull a file full of passwords into a repo, beware who else can read it... [17:36] ah, noone will, but i am still afraid that it'll scan the whole system [17:39] hi. I just found out that bazaar tracks changes in the execute bit of the files. Just out of curiosity, is there any way I could tell bzr to ignore that bit on certain files? [17:41] or, is there a way to see in what what did the permissions change? [17:42] ricardokirkner: atm you can only ignore /all/ changes on a file [17:43] ricardokirkner: bzr log -v will show a "*" next to the file [17:43] whenever the execute bit changes [18:35] jelmer: pong [18:51] a bzr push to launchpad got cut midway because I lost the internet connection, now I'm trying to push again and it tells me it can't create because it already exists [18:51] how do I fix this? [18:51] bzr: ERROR: Can't rename ... already exists [18:51] LarstiQ: Was just wondering whether there was anybody workin on nested trees atm [18:51] LarstiQ: Also, are you going to the sprint? [18:51] jelmer: I don't know. [18:51] (on both accounts) [18:51] k [18:52] luisbg: bzr break-lock $URL [18:52] jelmer: I'd like to, but atm I'm not really contributing anything. [18:52] Peng, sorry for the hazzle but what should the $URL be? [18:54] the push location? going to try :) [18:55] Peng, thanks a lot!!! [18:55] :) [18:57] LarstiQ: I still have time for the occasional bzr-svn patch, but shallow branches are still on my list :-/ [19:04] Uhm, how do I reverse a revision? [19:04] peng: like uncommit? [19:04] or commit the reverse of it? [19:05] Latter. [19:05] "bzr merge -r 10..9 .", right? [19:05] It's doing nothing. [19:05] yep [19:06] and commit [19:06] Well it's not doing anything. [19:06] It says "All changes applied successfully." but doesn't change a thing. [19:06] bzr st doesn't show anything either? [19:07] Correct. [19:07] does not specifying "." change anything? [19:08] it shouldn't, I think, but I never specify . [19:08] Try bzr di -r 10..9 first, to see if that revision actually has any changes [19:08] It's possible to make empty commits [19:16] New bug: #181585 in bzr "bzr push --create-prefix sftp:// crashes" [Undecided,New] https://launchpad.net/bugs/181585 [19:33] Oops, forgot about this. [19:34] jelmer: I dunno. It contacts the server. [19:34] LeoNerd: It added a few files. [19:34] jelmer: Yeah, that worked. [19:34] Why? [19:37] re [19:37] re? [19:37] with a path means a cherrypick I think [19:37] Um. [19:37] So? [19:37] Of course it's a cherrypick. [19:37] no, it's an inverse cherrypick [19:38] I'm not trying to justify it, it is a bug. [19:38] there are probably two codepaths [19:38] one that works on a part of the tree (when a path is specified) [19:38] and one that works on the full tree (when no path is specified) [19:44] well, without a path [19:44] the -r argument refers to the remote/parent location, ain't it so? === niemeyer_ is now known as niemeyer [19:57] yes, but in the root of the branch, "." does change the meaning === Peng_ is now known as Peng [20:13] jelmer: ah [20:13] jelmer: I thought it just meant "this branch", at least for merge [20:13] sorry [20:13] I meant *does not* change the meaning [20:14] bad typo [20:29] What did I miss? [20:30] Last I saw was "the -r argument refers to the remote/parent location, ain't it so?". [20:44] My experience is that "." is required for this sort of backout "merg": "bzr merge -r10..9" gives me an error, but "bzr merge -r10..9 ." seems to work. [20:45] Yeah, and just now for me, . did nothing and no-. worked. [20:45] I'm assuming that "bzr merge -r10..9 ." is *the* way to reverse a commit so I can commit it again; I discussed this recently in here actually. If there's a better way, I'm all ears. "cherry pick" sounds bad to me now because of it messing with merges in general, but I'm not sure it's a problem for this case. [20:45] (but no-. contacted the server) [20:46] FWIW, hg has a "backout" command to do it. It also makes the new revision a child of the old one. [20:46]