[00:01] spiv, hope you get well soon [00:01] win 2 [00:01] poolie: Sure. [00:27] how long should doing a "bzr upgrade" on a bzr+ssh URL take? [00:27] time to pull fully, time to push fully, roughly [00:28] faster if there is an optimised case for it [00:28] lifeless: ah, so it pulls, does the work locally, then pushes? [00:30] okay, strace shows that now... the upstream bandwidth was so low I wasn't seeing it my monitors. :P [00:30] the progress bar isn't very helpful. :) [00:55] AttributeError: 'SvnWorkingTree' object has no attribute '_transport' (in bzrlib.workingtree.WorkingTree.read_basis_inventory) trying to branch from a svn repo into a bzr one. [00:55] bzr 1.6, bzr-svn 0.4.12 [00:56] (ubuntu packages, with http://ppa.launchpad.net/bzr/ubuntu) [00:58] ...hrm; looks like the branch operation succeeded; no working tree generated, but "bzr update" in the target location fixes that... [00:59] ...and "bzr check" claims everything's in good shape. [01:04] nDuff: please file a bug [01:04] nDuff: I suspect you did branch NEWPATH [01:04] and its probably not tested by bzr-svn's test suite [01:04] where NEWPATH was under a preexisting shared repository [01:04] ...but yes. [01:04] we need an appeals process for reviews! ;) [01:06] markh: we have one; Reply. [01:07] or more reviewers :) [01:08] yeah, but if the complaint is about stylistic issues, hitting reply will just start a huge debate about stylistic issues... [01:09] markh: a review is a dialog, no more no less [01:09] I guess I mean the vote then [01:09] if a particular reviewer feels that some stylistic issue is sufficiently important to make it a requirement to land... [01:10] then either a) they are right, or b) they are wrong - and either way we should discuss it [01:10] an 'appeals process' sounds like a formalised huge debate IMO :) [01:10] or I should just stop complining, submit to the request and re-re-submit [01:10] and sigh :) [01:10] I'm happy to give my opinion if you tell me the thread === thumper_laptop is now known as thumper [01:25] ...filed as bug 264548 [01:25] Launchpad bug 264548 in bzr "AttributeError: 'SvnWorkingTree' object has no attribute '_transport' during branch" [Undecided,New] https://launchpad.net/bugs/264548 [01:27] nDuff: thanks [01:33] jam: still around? [01:36] hello jml [01:36] do you still have teeth? are you back in sydney? [01:38] poolie: some. no. [01:38] poolie: back late tomorrow [01:39] robert and andrew were going to work here on friday and then maybe go to the pub, you're welcome to come if you want (to either part) [01:39] poolie: I'll be landing at about 10:30pm [01:39] but thanks for the invite :) [01:39] maybe next time === kiko is now known as kiko-zzz === mw is now known as mw|out [01:55] internet! [02:04] Is yours? [02:16] know a trick to check history of a single file ? [02:16] with 'viz' preferably [02:16] to easily check actual diffs between revs [02:25] abentley: does bb match the /exact/ sender field, or only the email portion ? [02:25] lifeless: The exact sender field. [02:25] strk: well, log -v FILE is probably close to what you want [02:26] strk: I don't think viz has a per-file mode at the moment [02:26] abentley: oh. can you tweak an email address in bb for me then? user adri [02:26] strk: folk generally use annotate though, to look at a file [02:27] lifeless: Sure. [02:27] abentley: Adrian Chadd [02:27] I had just put in the email component [02:27] strk, with gannotate you can doubleclick lines to see the diff iirc [02:27] it would be nice to get viz too [02:28] wow, annotate got to my conclusion in a shot [02:33] great [02:35] lifeless: Done. Note that it is an exact match, so I used "Adrian Chadd" [02:36] thanks === strk is now known as strk_off [03:57] back soon, shopping run [05:29] poolie: hi, I've reviewed the locks hook patch john said resubmit: to; I'm also asking for resubmit. [05:55] lifeless: my patch? [05:57] I wrote a patch to hook locks [05:57] you updated it [05:57] I needed it today, and realised it was still unmerged [05:57] now you want me to update it again and resubmit it? [05:58] I'm happy to do the update [05:58] we need to agree on how it should look though [05:59] ok, i'm just preparing to send something then will look at it [06:00] so [06:01] my patch makes these hooks inconsistent with the other ones [06:01] i agree the inconsistency is bad, and um [06:01] to some extent the lack of testing is bad, though iirc the way it was done in the old code was not tested either [06:02] i think the existing interface is both a bit unsafe and longwinded, but [06:02] the old code doesn't try 'restore to pristine' or clone a hooks object [06:02] uhm, anyhow [06:02] yeah, anyhow [06:02] let's not block this on changing that [06:03] so, i think at least having specific names for that behaviour lets you think about changing it [06:03] s/changing/testing [06:28] lifeless: mini review sought of http://pastebin.ubuntu.com/43261/ [06:31] poolie: looks good [06:31] great [06:32] anything missing? [06:32] well, before you start [06:32] anything missing that people are likely to misunderstand [06:34] nothing comes to mind [06:34] bbiab [06:34] kthx [06:37] howdy! I'm a total bzr n00b and really just want to accomplish one thing. i'd like to checkout only a subdirectory of the trunk. this is easy with other vcs' like svn -- can it be done with bzr? [06:37] j00bar, you can't do that yet [06:37] j00bar, it will be possible in a few versions or so [06:37] sorry [06:38] j00bar, if the subdirectory is a branch, however [06:38] then you can [06:38] bugger. [06:38] it's a python project where the subdir has the actual code and the branch root has INSTALL, README, etc that i don't really want -- with SVN or other systems, i just check out the subdir and update as needed... [06:38] j00bar, most DVCS's you'll find don't support partial checkouts yet [06:39] but if it can't be done, it can't be done -- no worries -- thanks!!! [06:39] np [06:56] Goood morning Bazaar [07:50] hi visik7 [07:50] meh [07:50] hi vila [07:51] hi :) [07:51] :P [07:53] brane is flied [07:53] * lifeless halts() === RAOF_ is now known as RAOF [10:59] I'm having a problem with bzr-svn 0.4 and bzr 1.5 shipped with fedora [10:59] This is written to my .bzr.log: AttributeError: 'module' object has no attribute 'properties_handler_registry' === asabil_ is now known as asabil [11:08] jdahlin: you have a mismatch between bzr-svn and bzr versions [11:08] I think your bzr-svn is too new [11:08] yeah, I reverted a few commits and it appears to work now [11:33] Hmm, strk has gone [11:33] qlog has a per-file mode [11:50] markh: Hi there, are you building the bzr-svn extensions for windows? [11:51] markh: I've got a build error, did you run into this - error LNK2019: unresolved external symbol _svn_auth_get_windows_ssl_server_trust_provider referenced in function _get_windows_ssl_server_trust_provider [11:59] Never mind, looks like it's a "no longer supports svn 1.4 libraries" thing [13:00] I have two questions: 1) what is "subtree support" 2) what is "rich root". Both are mentioned in bzr help formats, but I have been unable to find anything more detailed, like what it actually means [13:00] and yes I have tried google [13:13] AnMaster: they are related, iirc [13:13] subtrees are when you have a branch, which in turn incorporates another branch [13:14] subtrees let you manage that better [13:14] um you mean like svn:external? [13:14] or something else? [13:14] i think so, yes [13:14] ah ok [13:14] rich roots are where there is a unique ID associated with the branch root, iirc [13:14] it's a watershed - once you move the branch to a rich root format, you can't go back [13:15] and generally, it should only be done once across a community, iirc [13:15] so we haven't yet made it the default [13:15] abentley would know more [13:16] hm ok [13:19] sabdfl, AnMaster: The relationship is that rich roots are a prerequisite for subtrees support. But it turns out they're also useful for bzr-svn, which is why we provide formats supporting them. [13:19] hm ok [13:20] abentley, so subtree is basically same as svn:externals? [13:20] AnMaster: Yes, but that feature isn't finished yet. [13:20] right [13:22] anyway that is not a feature I need, features I need/want are: 1) cherrypicking like darcs 2) faster push/pull for huge repos (close to git's speed preferred, but with the usability of bzr) 2) something like svn:eol-style [13:23] err make the last one 3) heh [13:26] AnMaster: We want to improve cherrypicking support, but we don't want to implement it the way Darcs does. Their approach to patch handling leads to performance and integrity problems. [13:26] hm ok [13:26] I'm having a problem with the trac-bzr source browser, and I'd like a little help in debugging it. [13:26] The other two are currently in development. [13:28] My trac install consists of a plain directory containing a number of shared repositories with branches beneath them. [13:28] When browsing the root of one of the branches, I get an error like this: NoSuchRevision: KnitPackRepository('file:///path_to_shared_repo/.bzr/repository/') has no revision (revision) [13:29] Is there any way I can find out why the browser thinks it needs that revision? The repository and branch seem to be working fine in general use. [13:29] abentley, basically I need to merge bugfixes back to a stable branch from trunk (and sometimes the other way too), bzr can't handle keeping track of what revisions have been merged and what ones haven't. [13:29] not when you skip some non-bugfix revisions in the merging [13:30] Right. We do want to add that, though no one is currently working on it. [13:31] well I would if I was a python programmer [13:32] * awilkins wasn't a Python programmer before he started scratching his own issues on Bazaar, but appreciates not everyone has the time to take out on solving problems in other projects [13:34] For me the choice was - use SVN and implement my own merge tracking or - use Bazaar and resolve any other issues you might confront [13:34] So far I'm _very_ glad I chose Bazaar [13:34] awilkins, at least I don't have time before next summer holidays [13:35] AnMaster: What you are wanting is the tracking of cherry-picks [13:36] AnMaster: Have you tried a different merge algorithm? You may get more joy with something like --weave [13:37] AnMaster: if you make the bug fixes in the stable branch first, you can continuously merge the stable to the trunk [13:37] * awilkins was just about to say that too [13:37] there's a page about this somewhere [13:37] I can't remember what it's called [13:38] anmaster: here it is: http://www.venge.net/mtn-wiki/DaggyFixes [13:41] So a combination of "bisect" to test for the bug presence, a branch, and a forward-merge (to both the stable bugfixing branch and the trunk) might work more cleanly (but is obviously slightly more of a PITA) [13:44] hm will try that [13:46] Thanks for asking, I like learning new ways of doing things :-) [13:51] Is there a command to check for the presence of a revision ID is a shared repository (or something I can use to achieve the same)? [13:52] bzr revision-info -r revid: ? [13:52] Hmm, not sure about the shared repo bit [13:53] Yeah, it complains about it not being a branch [13:54] You could stat -c it. revision-info will blow up if that rev isn't in the current branch. [13:55] (other similar things like diff or testament would work too) [13:55] Thing is, I don't know which branch the revision was been created against :) [13:55] was been? [13:55] pickscrape: it doesn't matter. [13:56] (of course, revision-info should be a little more polite about failing, but that's neither here nor there) [13:57] If stat and diff work with revid: (regardless of branch) then so should revision-info IMHO [13:57] Oh, so it will search the entire shared repo regardless of whether the revision in question is a part of the branch's history or not? [13:57] pickscrape: Yes. [13:57] Sweet, thanks. [13:57] awilkins: Well, but revision-info wants to show the revid. [13:58] awilkins: Er, I mean 'revno'. [13:58] That fares poorly when the revision isn't in the branch... [13:59] Ugh, yes [14:00] Thanks all, that's confirmed my theory. The revision that trac-bzr is complaining about exists in one of the other shared repositories. [14:00] So the next question would be, why would it be picking up that revision in the first place... [14:03] how can you commit with sub revision numbers e.g. revision no 7.3 [14:03] if i do bzr commit -m "blah" it always gives me a whole number [14:04] the help doesn't have any info on this [14:04] EarthLion: Sub numbers are always nested revisions of merges [14:04] EarthLion: Revisions committed on the branch you are on are always single integers [14:05] awilkins: "Sub numbers are always nested revisions of merges" can you explain what that means [14:06] EarthLion: revisions numbers with more than one component are used to identify the revisions that are part of merges from other branches [14:06] You cannot commit revisions with more than one number in the branch you are working on [14:06] ah ok i see thanks for explaining === kiko-zzz is now known as kiko [14:43] awilkins, ping === mw|out is now known as mw [14:48] I am still a bit confused between bzr init and bzr init-repo for an initial project; can someone give me why I would use bzr init-repo to start a project vs bzr init? [14:48] Oh, well, that's easy. You wouldn't :) [14:48] haha [14:49] init creates a branch, that you have files in and work in. init-repo creates a repository, that a set of branches can use to share common history. [14:49] ericvw: init-repo only makes sense if you plan to have multiple branches and want to use shared storage for them [14:49] ericvw: but you can always convert later (trivial) [14:49] ericvw: (just branch your branch into a repository and you're done) [14:50] uws: Or use reconfigure :) [14:50] uws: So if I had a branch with bzr init, and I decided to create a repository and wanted to add that solo branch to the repository what command should I look into? [14:51] But for individual or small peer use, I could probably get away with a init-rep [14:51] init-repo* [14:51] ericvw: You'd need to init-repo in a parent dir of your branch (or alternately, init-repo somewhere and move that branch into a subdir of it), then use reconfigure --use-shared. [14:52] fullermd: ok, I will experiment with this, thanks! [14:52] ericvw: init-repo doesn't give you somewhere to work; it's not an alternative to init. It's a potential enhancement for some use-cases. [14:52] so in contrast to svn, the definition of repo is something different, right? [14:53] If you only ever have one branch, it doesn't gain you anything. If a project is tiny, you probably wouldn't be able to notice what it gains. [14:53] Well... yes, and no, and totally, and kinda. [14:53] yeah, that is what threw me for a loop at first [14:54] init-repo doesn't [shouldn't] change anything about how any commands work. [14:54] There's no semantic difference between doing $SOMETHING among two branches that are in the same shared repo, doing $SOMETHING among two branches in different shared repos, doing $SOMETHING among two branches neither of which is in a shared repo, etc. [14:55] ok, i think i am getting the concept now, I will have to re-read the guide again to get a better understanding [14:55] For the purposes of initial experimentation, you can forget init-repo even exists. [14:55] You can switch to using it (or away from using it) on a given project at the drop of a hat. === thekorn_ is now known as thekorn [14:56] fullermd: thanks for the explanations and help! [14:56] uws: you too as well :D [15:03] I am a little confused in doc-guide section 4.2.2 It talks about creating a repo and then grabbing a branch from someone else...; so in a 2 person environment, you may each have your own repo with a branch within it? [15:06] ericvw: It is possible to do that, but the whole point of a shared repo is to put branches in it. [15:07] abentley: ok, thanks [15:09] when did bzr branch including tree generation get so freakingly fast? [15:11] jelmer: I think in 1.5 or 1.6 [15:11] jelmer: That was a bit of a team effort with ianc. [15:11] We're currently hamstrung by poor index performance, though. [15:12] I would *like* to be competitive with cp, at least in a shared repo. [15:12] I was quite impressed [15:12] and still am ;) [15:13] I still shudder to think what managing wine's repo in bzr would be like though [15:21] abentley, Thanks, it's now at least quick enough to "feel" instantaneous on non-huge trees [15:29] any idea why attempt to push from laptop to desktop machine fails - see log http://rafb.net/p/okZ1bY72.html [15:30] zbrown: don't know about wine's repo, but from today my machines are m$ free - i was finally able to make some proprietary folio infobase running under wine - no need for Virtualbox & similar emulators any longer :-D [15:32] gour: could you try bzr push nosmart+bzr+ssh://gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/.bzr/repository/ [15:32] Sorry, skip the end. [15:33] bzr push nosmart+bzr+ssh://gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/ === beuno__ is now known as beuno [15:40] abentley: same - http://rafb.net/p/pwZZw175.html [15:40] let me check if i push to the right dir [15:42] gour: cfgfiles looks like it already has a repository. Is that intentional? [15:42] hmm, the gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/ has the following format - gour@gaura-nitai.no-ip.org/home/gour/repos/bzr/cfgfiles/ [15:43] oops, http://rafb.net/p/3c0gT377.html [15:43] and bzr upgrade says: The branch format Bazaar-NG meta directory, format 1 is already at the most recent format. [15:44] * gour thinks that having less supported formats would be better [15:44] gour: Right. Rich-roots are not a default format. [15:44] gour: Talk to Jelmer. [15:46] abentley: ok. explicit upgrade to --rich-root-pack solved it [15:49] anyone responsible for bzr-gtk here? [15:53] ohh, it seems we solved it... [16:04] gour: haha, well I'm glad to hear it :). We (the wine contributors) are pleased with how far wine has come in the last few months [16:09] zbrown: i was dreaming several years to become 100% free. used win4lin, vmware, vbox...all bloatware [16:12] zbrown: Do you know offhand how well Wine supports Adobe Premiere? [16:17] abentley: can't say I do know [16:18] abentley: reports seem to indicate its not that great though [16:18] gour: Eh I hardly find vmware to be bloatware [16:19] gour: at least on my laptopt, its very responsive, not quite "real system" but its still better than most [16:19] zbrown: Too bad. I have a friend who wants to use Ubuntu, but must use Premiere. [16:21] abentley: its getting there, its just not all the way there yet [16:22] hard to hit a moving target like Microsoft :) [16:27] zbrown: bloatware in the sense that i required the whole OS to run single apps for which there is no native-linux replacement [16:27] zbrown: But most applications are backwards-compatible with XP or 2000, no? [16:29] microsoft is a moving target? if anything they're moving backwards and making things constantly easier for us [16:36] Toksyuryel`: not when you're trying to emulate (sometimes broken) behaviors of the OS that applications depend on [16:37] abentley: What are you particularly referring to? As of right now, emulation in wine is targeted for NT 5 series [16:37] so 2000, XP and 2003 are the main goals [16:37] granted XP is the focus [16:37] zbrown: So those targets haven't moved for 5 years. [16:38] abentley: API's change with service packs and security releases ;) [16:38] abentley: not to mention the api is just way huge [16:38] zbrown: oh, I get what you're saying now [16:39] zbrown: That I can certainly agree with. [16:39] Its only hard because there's maybe 20-30 regular contributors, probably <20 [16:39] and MS has thousands of people changing things on us ;) [17:11] Odd question, it doesn't make sense to have a repo with checkouts within it does it on a local development environment? [17:12] I understand the using shared storage for 2+ branches in a shared-repo in a development environment. === kiko is now known as kiko-fud [17:37] abentley, speaking of which.. [17:38] abentley, What's the latest status in your discussion with Robert about rich-root-pack as default? [17:38] jelmer: We haven't talked about it in months. [17:39] oh, ok. I thought I saw something about it recently [18:01] awilkins, ping [18:07] Did anyone happen to answer my question when I left temporarily? [18:09] jelmer: ping, did you see my mail about 'Re: transport implementation test scenarios and rabbit-holing' ? [18:10] jelmer: there are two questions for you (search for jelmer in the body :) [18:17] I only see the email from mwh [18:30] jmm, ericvw quit just a bit too early === vednis is now known as mars [18:36] jelmer: strange, I replied and added you in CC your email @samba.org is still valid ? [18:36] jelmer: maybe it's not in the bzr folder === kiko-fud is now known as kiko [18:46] vila, LarstiQ: nope [18:53] What is the primary difference between checkouts and branches? [18:56] jelmer: here is a digest just for you http://paste.ubuntu.com/43429/ :D [18:57] vila, which python-kerberos did you install? [18:58] you'll need at least 1.0+svn2455-1 [19:00] vila, you have a kerberos environment? [19:06] good afternoon, i'm working on setting up a bzr branch of a subversion checkout, how do i go about ignoring all the .svn directories under the different folders? [19:07] i think i need to edit a .bzrignore file but not quite sure i need to do [19:08] jjesse: "bzr ignore .svn" should be sufficient [19:09] yeah [19:09] jam thanks [19:09] when doing a checkout, does the .bzr have the same characteristics as branch since i can bind/unbind? === mark1 is now known as markh === mw is now known as mw|food [19:21] In the 1.1 project/trunk layout design, are those 'container' directories branches or just folders? [19:45] vila, hi [19:45] vila, ? [19:57] just a reminder to beuno, jelmer, vila, et al. Today is bug day [19:58] please triage, fix, and otherwise do interesting stuff to the bug tracker [19:58] (I know Jelmer did work last weekend, but *today* is the official bug day) [19:58] jam, cool! bug day finally happened! I like you as release manager :) === mw|food is now known as mw [20:09] oddly enough, I'll actually have released 3 versions in a row [20:09] I released 1.5 [20:09] and then accidentally inherited 1.6 [20:09] and now I'll be doing 1.7 [20:09] :) [20:10] jam, and doing a great job at it, really [20:10] I'll say I'm more comfortable with it now that I've done 7-ish actual releases :) [20:10] Peng: so if you count 1.6.1rc2 + 1.6rc5 you could claim rc7 :) [20:11] oh there is a bug day? [20:12] gah, why does ericvw keep disappearing! [20:38] I'm doing some code cleanup in a source tree and I'm trying to understand the subtleties of bzr rm versus just rm. [20:38] I want the code to still be available using bzr log / bzr diff / etc. [20:39] Is there a difference between the two: bzr rm vs. rm? [20:40] bzr status shows files as removed using either command. [20:41] theuiguy: you could bzr rm --keep and still have the actual file, but removed from a version control point of view. [20:41] theuiguy: bzr rm is explicit, just rm is implicit. [20:42] LarstiQ: I think I want the opposite -- I want the file removed from my tree, but still have it in version control if I ever need to go back to it. [20:42] theuiguy: well, you still need to commit. [20:43] It seems like just rm is what I should use. [20:43] theuiguy: with any (rm, bzr rm, bzr rm --keep), after you commit that file won't show up anymore, but still be present in historical revisions. [20:44] LarstiQ: Are you sure? That's not what I'm seeing at the moment, admittedly before I commit [20:44] If I do rm, I can still do bzr log FILENAME and see FILENAME's history [20:44] theuiguy: I'm very sure, but I could be more precise about "won't show up" [20:45] but with bzr rm, it doesn't show the history anymore [20:46] LarstiQ: Please do be more precise... I want to understand this [20:48] theuiguy: right, so the difference between bzr rm and rm *before commit* is that because the plain rm is implicit, the file will only not be in the inventory after you committed. Whilst bzr rm has a bit more info and can already do that. [20:48] theuiguy: they'll be exactly the same after you commit. [20:49] jelmer: see my patch in https://bugs.launchpad.net/bzr-svn/+bug/263570 [20:49] Launchpad bug 263570 in bzr-svn "bzr-svn cannot be compiled for Subversion 1.5.* without hand-editing setup.py" [Undecided,New] [20:49] theuiguy: all revisions henceforward will not have that file in their inventory. It might still be in your tree if you did bzr rm --keep, but status will say it is an unkown file. [20:49] theuiguy: if you do a fresh checkout, or remove the file and then revert to a revision, the file will not be recreated. === Snaury__ is now known as Snaury [20:49] LarstiQ: So after commit, how would I be able to look at the history of the file? I'd have to revert? [20:49] theuiguy: however, if you revert to a revision before it was removed, the file _will_ be created in your working tree. [20:50] theuiguy: hmm, it seems there might be a regression there. [20:50] theuiguy: you should be able to provide a file path that doesn't match the current state, but a historical one. [20:50] theuiguy: you could always revert, yes [20:50] LarstiQ: It's probably just our older version of bzr [20:51] theuiguy: or say, use bzr cat -r rev to see how that file looked in a certain revision. [20:51] theuiguy: what part of the history of that file are you interested in seeing? [20:52] LarstiQ: Well, I'm doing some code cleanup in our tree... files that I don't think we'll ever need again [20:52] but I want to be sure I can get back to them if we ever need them [20:53] bzr rm scared me because the behavior before commit makes it look like the files are completely gone. [20:53] including all knowledge of what went on in prior revisions [20:53] theuiguy: I can see that, but I can reassure you that is not the case. [20:54] theuiguy: so I think that is a ui bug that needs to fixed to be less scary. [20:55] Is it a recent addition that you should be able to provide a historic path to see history? [20:55] as in bzr log -r OLDFILE [20:55] with some revision information of course [20:56] Or does that not currently work? [20:56] theuiguy: it doesn't do that on my recent copies. So either it used to be possible, or I misremeber wrong. [20:56] theuiguy: but it works for cat [20:58] theuiguy: I think I was confused with cat. [20:58] hmm... so it does work for cat? [20:58] theuiguy: but I still think it might be a nice feature. Although I acknowledge it can be tricky to infer what the user means. [20:58] theuiguy: yes [20:58] theuiguy: bzr cat -r path/to/file [20:59] theuiguy: should work even with path/to/file not existing in the current revision. [20:59] ah... it'd be nice if log could do something like it ending with "deleted in revsion X" [21:00] theuiguy: well, removed is relatively simple [21:00] theuiguy: but consider files that are moved around. [21:00] theuiguy: especially if you swap files a and b [21:01] theuiguy: what does 'bzr log -r rev a' mean? [21:01] LarstiQ: So let me see if I understand: bzr rm or rm both say remove this file as soon as I commit this and don't track it any more [21:01] but ... [21:01] theuiguy: give me the information for the file that is currently at path a, or the one that was at a in that revision? [21:01] they are still in revision history for previous versions [21:01] theuiguy: exactly. [21:02] theuiguy: bzr very rarely destroys history [21:03] LarstiQ: that's very reassuring. Thanks! [21:03] theuiguy: and if it does, always on explicit user request (bzr rebase for instance) [21:03] LarstiQ: It doesn't seem like bzr handles the simple case where there's nothing there in the current revision [21:04] Is rebase built in now? Or still a plugin? [21:04] theuiguy: you mean, bzr log foo when foo isn't present? [21:04] theuiguy: plugin [21:04] LarstiQ: yes [21:06] theuiguy: right, it's relatively straightforward in the case where there only ever was one file with that name. [21:06] theuiguy: in the other case, maybe log should be more interactive, and present you with a list of different files that had that name, and ask which one you want. [21:06] It could be helpful to know [21:06] especially if there are file renames in there [21:07] Or perhaps just show renames in and out of that filename... [21:07] with the log only showing what was there at various revisions [21:08] renames would be the common case of that problem, it's also possible to just do serial adds and removes. [21:10] LarstiQ: So the difference in behavior before commit between bzr rm and rm is accidental, right? [21:11] theuiguy: I don't know for sure, but the difference sounds logical to me. It's not of much significance though. [21:13] Hi all. On the server where my canonical trees are, I wish to have some code that marks bugs as updated when branches are pushed-to with revisions that mention those bugs. My current idea involves cron, but I'm having trouble. [21:14] chadmiller: you're not using --fixes? [21:14] It looks (I think) like merges can rearrange my trees so that merely keeping track of the last-seen revision-id and constucting a list from that to the end is not sufficient to know what to update. [21:15] LarstiQ: No. I perhaps could, but I don't think that solves my problem. [21:15] chadmiller: it doesn't, but makes the detecting of fixed bugs less iffy. [21:15]