[00:12] Peng_: ping [00:46] If I "bzr init-repo A; bzr branch (url) A/test1; mkdir -p A/B; bzr branch A/test1 A/B/test2" [00:46] then, "cd A; bzr multi-pull", will multi-pull "know" to always pull in the correct dependency order? [00:47] Yes, but no. [00:47] Ok, thanks! Bye! [00:47] Just kidding ... pls 'splain [00:48] Yes, it will pull in "correct" order there, but not because of any sort of dependancies. [00:48] fullermd: Hrm. How's that? Order of creation? [00:48] multi-pull doesn't do anything more than "for i in `bzr branches`; do (cd ${i} && bzr pull); done" [00:49] alphanum order, then? [00:49] Lexical ordering of the paths. At least, I'm pretty sure it orders 'em. [00:51] fullermd: hrm. doable, then -- but a bit fragile. other than multi-pull, *IS* there a 'better way', then, to build a hierarchy of dependent branches, and, auto-update the whole shebang -- in correct dependency order? [00:51] Not pre-built. You could probably bang up something to pre- or otf- build a graph and walk it. [00:52] Though I wonder why you'd just have a long chain of copies of the same branch. [00:52] Presumably you'd actually have changes around, and be merge'ing rather than pull'ing, which generally means interaction anyway. [00:53] fullermd versioning modules, core hacks, and site code for multiple drupal sites can be such a joy [00:53] If it's a single series, loom could do some level of automation, but that doesn't help you once the branch graph branches. [00:53] loom? looking ... [00:54] as in http://www.isi.edu/isd/LOOM/ ? [00:54] It's a tool for automating having branch A, with branch B based off that, with branch C based off that, with branch D based on that, with... [00:54] But it doesn't help when you have branch A, with branch B based on that, with branch C also based on A, with branch D based on B, with branch E based on D and C, with... [00:54] ah, heh -> https://launchpad.net/bzr-loom [01:02] fullermd: Comparing levels of pain/confusion, your point's looking better by the moment" "... generally means interaction anyway ..." [01:03] 5 minutes of manual interaction versus the possibility to fubar the whole mess -- under script control. [01:03] methinks "Door #1" is the saner option ... [01:04] Scripts are inanimate objects. Inaminate objects are volitional entities hell bent on imposing any perversity imaginable on anybody in range. Basic precept. [01:05] Well, some of the emplyees around her are inanimate objects as well ... more similar to voles than volitional entities. But point taken. [01:05] {employees, here} [01:06] Exactly. People are safer. It's like the difference between genius and stupidity; genius has its limits. [01:08] fullermd: Heh. I could extend that argument to DVCS vs sneaker-net-n-punchcards, but been there, done that already ;-) [01:10] I need to write down the sequence of steps that I use that sometimes results in bzr concluding that the directory foo has been renamed to foo [01:10] and try to figure out why it happens. [01:10] I keep being in too much of a hurry when it does. [01:36] Kilroo: 'foo has been rename to foo'? [01:40] *renamed [01:42] Yes. [01:42] I get a rename conflict on a directory with the same name. Haven't stopped to figure out why yet. [01:43] I am having trouble recalling what I'm usually doing when it happens. [01:43] this can happen when two people add the same directory independently [01:44] which is a known bug [01:44] spiv, did you see https://answers.launchpad.net/loggerhead/+question/108796 ? [01:48] Ah. [01:48] Well, that would explain it, even though I added them both. [01:48] poolie: hmm, no, I hadn't. [01:52] you should subscribe to answers if you're not already [01:53] I'm still debating what I want to do about the fiasco of "version control" we have at work... [01:54] I am, but apparently not for loggerhead. [01:55] I think, if either I can't get them to change how we're doing it at all OR I can convince them to move source code out of subversion completely, I'm going to end up pushing hg; if I can convince them to restructure the repositories sanely but they insist on sticking with subversion, I might stick with bzr. [01:56] Personally I like 'em both, but for purposes of adoption by the rest of the team I think HgEclipse might make the difference between getting brushed off and being given serious consideration. [01:56] Still experimenting though. [02:38] jam, still here? [02:54] I wonder if I'm going to end up fouling myself up by having a lightweight checkout for switching among the branches of a shared no-trees repository in .bzr/r. [03:03] jelmer: pong [03:11] poolie: No. jam /quit. [03:19] Kilroo: no that's pretyt standard [03:20] Ok. I didn't think it was too likely to foul up anything, but I also wasn't sure how common it was to put things under .bzr that bzr didn't put there for you. [03:24] oh i thought that was a typo [03:24] you should look at bzr-colo [03:24] it may confuse upgrade and things like that [03:25] hello. does anyone know if there is a timelapse view for bzr similar to this one (http://code.google.com/p/svn-time-lapse-view/) ? [03:26] check out bzr gannotate [03:26] but not directly with a slider afaik [03:26] thank you [07:18] Is there a way to make bzr ask for a username when executing bzr commit (with a remote url)? [07:19] I think some transports like HTTP can do that. [07:28] hi all [07:30] GungaDin: Like spiv said, http suports that, but most of the time you want to always use the same user to you specify it in the url (user@host) [07:30] and all protocols supports that [07:39] poolie: I can't find the tag for 2.2b1 in lp:bzr/2.2, it's associated with mbp@sourcefrog.net-20100401011841-9x637emlcah1a0qv9 [07:40] poolie: err, I can find the tag, but not the associated revision [07:40] * vila gets more coffee [07:44] hi there vila [07:45] i didn't end up merging that branch because i tried a last-minute merge of some fixes from gary [07:45] that ended up being rejected by pqm [07:47] poolie: no worries, just thought I mentioned it [08:01] hi all [08:07] hi there bialix [08:07] jelmer: if I want to check whether some directory has svn checkout inside, what method of bzr should I use? [08:07] hello poolie [08:08] there is open_tree_or_branch method [08:08] I need the way to ensure bzr clean-tree won't delete nested branches/trees/repos [08:08] any suggestions? [08:13] hmm, `bzr ignore foo` does not check for duplicates. I don't think it's good [08:21] that would be nice [08:21] obviously you can have globs that may overlap with each other [08:21] by precise dupes seem pointless [08:26] poolie: how you call in english any bzr object (branch/tree/checkout/repo)? [08:27] as cummulative name> [08:27] as cummulative name? [08:27] control component [08:27] mm, [08:27] so when I don't care what the bzr kind there but want to say "something which is bzr handle" [08:28] either branch or tree or ... [08:28] bzr control component? [08:29] guidance needed on https://bugs.launchpad.net/bzr/+bug/572098 [08:29] Launchpad bug 572098 in bzr "`bzr clean-tree` should not blindly delete nested branch/tree/repo" [High,Confirmed] [08:38] hm [08:38] bialix, i think if you do BzrDir.open it should tell you whether there is any control directory there [08:39] not specifically .bzr but also including .svn [08:39] thanks, that's what I need [08:41] Hello all! [08:42] So I was examining some history on bzr trunk recently, and saw something interesting... [08:42] the tag for bzr-2.1.0rc1 is at 4981.1.6, but the bzr-2.1.1 tag is at 4797.41.1 [08:42] ...which seems a bit odd. :-0 [08:43] That was meant to be :-) [08:52] Looking at it with qlog, it seems to make sense now. [08:53] qlog ftw! [08:53] trunk was merged into the branch for rc1, picking up some more fixes. [08:53] Definitely! [08:53] qlog is the best bzr tool there is! I use it *all the time*. [08:54] But it does make me think dotted revision numbers are less useful than I previously thought. [08:55] jszakmeister: and also slow [08:55] jszakmeister: they're human-readable [08:55] that's main idea [08:55] did you read recent thread from jam about history-db and dotted revnos? [08:55] Yeah, and they're easier to remember... but I wanted to assign some meaning to it, and you really can't. [08:55] Yes, I did. Good stuff! [08:56] It seems like a lot of trouble to go through to keep them useful though. [08:56] yep [08:56] but I was surprized that topo_sort is the main bottleneck though [08:57] Yeah, it was all very intriguing. [08:58] I would have thought something so visible to the user would have a simpler calculation... I was surprised by some of the answers in that thread. [09:00] * bialix nods [09:03] vila: ping === jszakmeiste is now known as jszakmeister [09:04] bialix: pong [09:04] vila: I have problems with selftest -s [09:04] wait a sec I do paste [09:05] vila: http://pastebin.com/UR68Awqc [09:05] I've added new test to bb.test_clean_tree [09:05] but selftest don't see it? [09:05] what I'm doing wrong? [09:05] gremlins? [09:06] bialix: "C:\Program Files\Bazaar\lib\library.zip\bzrlib" -- it's using the system-wide bzrlib. [09:06] rats [09:06] bialix: Run "./bzr selftest ..." or whatever the Windows equivalent is. [09:06] `python bzr` [09:07] Peng: wow ! Good catch :) [09:07] So another weird tag issue: bzr tags on bzr.dev shows: [09:07] Peng_: many thanks [09:07] bzr-2.2b1 ? [09:07] :) [09:07] now I can't run test at all :-( [09:07] jszakmeister: Yeah, I mentioned that poolie earlier, related to a pqm failure [09:07] bzr: ERROR: No module named testtools [09:07] it's not my day [09:08] Ow. [09:08] bialix: gee, that was changed sometime ago, you should run tests more often :-O [09:08] vila: I do run tests everytime. for qbzr and scmproj! [09:08] bialix: easy_install ftw [09:08] bialix: but not from bzr.dev it apperas [09:08] * bialix hates easy_install but it does not matter [09:08] appears [09:09] vila: I thought that's what you were asking. But how did the tag show up? [09:09] jszakmeister: bug most probably [09:10] Wait, now the bug is PQM is propagating tag too much? That's new. :D [09:10] I wouldn't think the tag would carry over without the corresponding revision... [09:10] :-) [09:10] jszakmeister: yeah, me neither :-/ [09:11] Would it be a PQM problem or bzrlib? [09:12] I'm curious if you can trigger this via the command line itself (I'm not sure how PQM does it's thing) [09:12] jszakmeister: I'm not sure, I guess pqm could be involved === khmarbaise_ is now known as khmarbaise [09:13] Hmm... maybe I'll play around a bit and see if I can trigger the issue. [09:13] vila: bzr get lp:testtools; cd testtools; python setup.py bdist_wininst -d.; run testtools-0.9.2.win32.exe <-- and no easy_install! :-P [09:14] jszakmeister: if you find interesting bits, please file a bug [09:14] vila: will do [09:14] bialix: wow === oubiwann is now known as oubiwann_ [09:15] bialix: worth giving feedback to the testtools project I think [09:15] Heh. I can reproduce it. [09:15] bialix: if only to tell them this alternative setup works out of the box [09:15] vila: testtools does not use setuptools and this is fine [09:16] vila: what kind of feedback needed? [09:16] everything is fine [09:16] bialix: yeah, that's good feedback :) [09:17] Looks like it's a known bug: https://bugs.launchpad.net/bzr/+bug/99137 [09:17] Launchpad bug 99137 in bzr "tags are "permanently" propagated by merge" [Medium,Confirmed] [09:19] jszakmeister: cool, thanks for checking ! [09:20] No problem! [09:20] I'm going to add a note to the ticket saying that we were both a bit surprised by the behavior, if you don't mind. [09:23] jszakmeister: sure, don't forget to click the metoo button [09:24] jszakmeister: that should enough to nudge poolie to provide an updated tad :-D [09:25] mm? [09:26] poolie: bzr tags -> bzr-2.2b1 ? [09:27] grrr bzr erro 'check your limbo', yeah, it's *empty* just get rid of it !! [09:27] ah, they propagate even if the merge is rejected [09:27] sorry [09:28] poolie: no worries, just a papercut :) [09:39] vila: yeah [10:01] Is there a way to get a list of the mainline revision ids between two revids, without the merged revisions (just the mainline)? [10:02] in code? [10:02] Or do I just need to use iter_merge_sorted_revisions and filter them myself? [10:02] poolie: yes [10:02] i thought you'd be able to get them directly [10:02] i don't recall the precise function tohugh sorry [10:03] No worries [10:03] jszakmeister: bzrlib.log._get_mainline_revs() , but note that it's private [10:04] jszakmeister: at least you can use it as an example [10:04] vila: Thanks! [10:19] ok good night all === jszakmeiste is now known as jszakmeister === TheMonkey is now known as ElMonkey [10:53] any pointers as to how to split off a sub-project from a repo without the sub-project retaining all unrelated history? [10:54] i'm in the situation that i'd like to release a part of a private project as open source, with the history, but of course wouldnt want the other parts of the project visible in the repo [10:56] ElMonkey: probably the easiest way is to use the bzr-fastimport plugin to export and filter a dump of the history, and import the filtered history. [10:57] ElMonkey: note that the history that will synthesise will have new revision-ids, so won't be easy to merge with the existing history [10:57] that wouldn't be a problem [10:59] know of any article that describes the process? [11:01] Does anyone know if you can limit the access to just the smart server over http? Or do I have to allow both smart and plain access to http? [11:12] ElMonkey: see the help for fastimport plugin and for fast-import-filter command. it's pretty straightforward [11:12] jszakmeiste: Sure, if your web server is smart enough (no pun intended). Smart requests are .bzr/smart. Dumb requests are everything else under .bzr. [11:12] jszakmeiste: Just curious, why? [11:12] bialix, looking at it [11:13] though i'm currently confused what they mean by front-end [11:13] as in "front-end | bzr fast-import-filter..." [11:13] ElMonkey: Whatever fast-outputs. [11:13] ElMonkey: for you frontend will be `bzr fast-export` command [11:13] Um. I hope. [11:13] ah, ok [11:13] OK then. :D [11:14] Oh, right, "export" is the word. [11:14] Peng_: I've got my server handling the smart requests, and I like that because I can easily put fine-grained access controls in front of it (check the authenticated user, and allow no access, read access or write access) [11:14] ElMonkey: it supposed to support conversion from other (d)VCS [11:14] jszakmeiste: Why can't you do that with dumb requests? [11:14] Because being authenticated doesn't mean that you should be allowed to view the branch [11:15] hmm, i can't fast-export a subdir, can i? [11:15] you can't [11:15] And it would dramatically increase the maintenance required as compared to our svn setup [11:15] my favorite topic detected: ACLs! [11:16] I thought building on Windows was your favorite topic. :D [11:17] phew! buildout kills windows builds for me [11:18] it seems my head is not robust enough to break the wall [11:27] spiv, bialix, thanks for the pointers, i think i'm on my way. just need things to re-appear at the right spot when importing [11:29] there's no way to make it keep stuff in a directory? [11:29] eg, i have source/foo.c etc i want to include [11:30] but they all end up in / in the new repo [11:30] i know i can solve this when importing [11:30] but what to do when i want foo/abc.h and bar/abc.h both? [11:33] or nevermind, i can apparently *not* make things reappear where they want even in the simple case... [11:45] the fastimport files are ok to be edited by a text editor, right? [11:45] i need to redact parts of some commit messages [11:57] hm, I need to go out in a couple of minutes so I better save this for later, but the new fix for bug 491763 has the same problem as the old one, [11:57] Launchpad bug 491763 in bzr "unhelpful OSError from rename inside transform" [Medium,In progress] https://launchpad.net/bugs/491763 [11:58] "%s %s %s" % (unicode, unicode, bytestring) is not safe. [11:59] and if someone who set up for building windows installers could test lp:~gz/bzr/support_OO_flag_installer that'd be great [12:02] ElMonkey: Yeah, go ahead. [12:02] a212901390231901: your nick is uhm, undescriptive ;) [12:02] ElMonkey: Obviously it'll change revision IDs and such if you import them into the same VCS as you exported them from, but if that's okay with you... [12:02] lifeless: It's Martin[gz]. All of his other nicks were taken. We have too many Martins, eh? [12:03] Thank goodness for {auto,tab}-complete. [12:03] a212901390231901: have you registered martin[gz] ? [12:03] Peng, thanks [12:04] in the UDS launchpad group you sent a link to? yes. [12:04] a212901390231901: on freenode [12:04] no, I'll pick something more sane next time I ping out. [12:05] if you register with nickserv [12:05] you can then kick off anyone grabbing your nick [12:06] I tried a bunch of different options I use on other networks and they were all taken, then I got annoyed ;) [12:07] :( [12:09] it's something of a miracle I've stayed on this long without being taken down by a brown out or my flakey hardware [12:16] You say "miracle" like it's a good thing. ;-) === oubiwann_ is now known as oubiwann [14:52] how do I specify a default format? [14:52] I get warnings about "Doing on-the-fly conversion from RemoteRepositoryFormat(_network_name='Bazaar pack repository format 1 with rich root (needs bzr 1.0)\n') to RepositoryFormat2a()." [14:52] rbriggsatuiowa: the default format is part of bazaar itself [14:52] rbriggsatuiowa: in that particular case the remote branch is in an older format and your local branch is in a newer format [14:52] so do I have to downgrade? [14:53] rbriggsatuiowa: fetching between two different formats is significantly slower than fetching between two branches with the same format === radoe_ is now known as radoe [14:54] * rbriggsatuiowa goes off to refresh his apt skills so he can install 2.0.3 [14:55] rbriggsatuiowa: you can either downgrade your local branch ('bzr upgrade --rich-root-pack'), upgrade the remote branch ('bzr upgrade ') or live with the slowneess [14:57] Can suppress_warnings suppress that warning? [14:59] I'm not sure [15:17] uhm did bzr just autopush? http://paste.pocoo.org/show/208074/ [15:19] http://bazaar.launchpad.net/~sproaty/whyteboard/development/changes hmm aparently so [15:21] speakman: more likely you're using a checkout or a bound branch, what does 'bzr info [15:22] ' says ? [15:22] * vila curses return key [15:22] me? [15:23] I think I did bzr bind yesterday while trying to solve pushing trying to push to http:// [15:23] rhaaa, /me curses xchat too [15:23] sproaty: yes you :) 'bzr info' ? [15:24] http://paste.pocoo.org/show/208077/ [15:25] sproaty: right, so you've using a bound branch,, the commit happens on the remote branch first and then locally [15:26] sproaty: there is nothing left to push in this case :) [15:26] was wondering why there was a pause after committing [15:27] sproaty: you can 'bzr unbind' and then 'bzr push' when you feel the need to publish your changes [15:28] alrighty then [15:28] thank you very much, vila [15:28] sproaty: you're welcome [15:28] bzr rocks, wish we were using it in work [15:28] no more damn .svn folders [15:30] jelmer: thanks for your help - I installed from source and things are going smoothly [15:30] also - just wanted to mention how awesome the bzr plugin architecture is [15:30] rbriggsatuiowa: np, great to hear :-) [15:39] hi, I noticed that while the home page mentions 2.1.1 as the latest, the SourceDownloads page carries only 2.1.0... [15:40] lelit: it's a wiki, feel free to update it [15:40] right [16:17] anybody seen this before? https://bugs.launchpad.net/bzr/+bug/572405 [16:17] Launchpad bug 572405 in bzr "push from windows machine to linux is broken" [Undecided,New] [16:18] I'm tempted to mark this bug as Critical [16:21] light checkout problem again === IslandUsurper is now known as IslandUsurperAFK === beuno is now known as beuno-lunch === BasicPRO is now known as iBasic === deryck is now known as deryck[lunch] === IslandUsurperAFK is now known as IslandUsurper === beuno-lunch is now known as beuno [18:41] Hello, I'm pretty new to version control in general, and after a ton of research I've decided I'd like to use Bazaar. I've got a Windows 2003 production server and a 2003 Dev server and a couple of developers running Windows 7. I want the developers to make changes on the dev box for testing and then periodically push those changes to production. [18:44] How do I approach this? [18:44] Two branches? [18:48] so you want dev->testsrv->production ? [18:48] Yeah [18:48] well, should be simple [18:49] all repos are "branches", if you will [18:49] so you just create a repo on each machine, and the push/pull appropriately [18:50] ElMonkey: so I need to set up an sftp server on each one? [18:51] ssh should do [18:52] dunno how bzr behaves with network shares, though, that might be simpler [18:52] ElMonkey: then the devs push to the dev server and I pull the final tested changes by running bzr on the prod server [18:52] they are in different physical locations [18:53] different networks, too? [18:53] yeah [18:54] for a long time i used a common repo on a usb flashdrive on one project, due to the computers not being networked [18:54] but anyway, ssh/sftp or samba shares should work [18:55] pulling from a network share should certainly work [18:56] Hmm, I think I'm still wrapping my head around decentralized ... === deryck[lunch] is now known as deryck [19:23] anyone here interested in helping me set up bzr on some windows servers for $25/hr ? [19:42] can someone explain about merging/branches? I've kind of done merging with svn at work, but not branches [19:44] like if I was to branch off to develop a new feature, that I see as being code-heavy, and then I find/fix bugs in the main code base that was branched from -- how do you like get the changes over into the other branch? [19:44] or is it a case of branching from trunk, working on that then merging that back into trunk [19:49] Generally, you just fix those bugs in the main branch. [19:54] then merge the 'new feature' branch back into trunk? [19:58] Well, not before the feature is ready to land :) [20:00] cool [20:09] how do I push a pending merge on top of a branch instead of merging all the revisions into one [20:09] ? [20:09] * cody-somerville forget he made a bunch of --local commits on a binded branch and ran bzr update. [20:13] ugh [20:13] bzr: ERROR: Selected-file commit of merges is not supported yet [20:14] I have changes in my working tree I don't want to commit :( [20:15] cody-somerville, you could `bzr revert --forget-merges`, and then commit your changes file-by-file. if they're more intertwined than that, I wouldn't worry about it too much [20:15] That's almost certainly a bad idea. [20:16] That's just going to lose those commits and get you a bunch of illogical and entangled new ones. [20:16] The first thing to do is get a handle on your previous head state. Update should have printed that out. [20:17] Assuming upstream hadn't moved, you can use diff to recover your uncommitted changes relative to that, and stash that somewhere. [20:18] Using another branch (or unbinind that one), you can use pull to jack back to that last commit. Re-apply the changes, commit them, Push over the upstream. [20:18] why wouldn't bzr revert --forget-merges not work? the commits were local and the master branch hasn't changed [20:18] Then stab --local in the eye with a #2 pencil. [20:18] err, sorry for double negation [20:18] Oh, it'll _work_. But I doubt it'll leave you where you want to be. [20:18] because it does indeed erase the commits you've already done. but it leaves the changes in the working tree [20:18] aye [20:18] so I can just commit now directly onto master [20:18] It'll leave you with all your local commits thrown away, and the sub of their changes (and whatever uncommitted stuff you had) sitting waiting to be committed. That doesn't sound healthy. [20:19] (s/sub/sum/) [20:19] fullermd, all the changes from my local commits were still sitting in the tree since it was a merge. [20:20] doing a merge is like uncommiting everything and then recommitting it as a single revision but keeping the history [20:21] It... umm... not with any meaning of those words I can dredge up... [20:22] Talking about "your changes" is ambiguous. [20:22] fullermd, sorry I mentioned --forget-merges. I should have just said "commit it anyway. it won't hurt." [20:23] You can take it to refer to the set of files as they now exist, or to the revisions you created. revert --forget-merges leaves the former intact, but tosses the latter. [20:24] IslandUsurper, on the contrary, I'm all good now thanks to --forget-merges [21:06] how do I see the full log entries for pending merge revisions? [21:07] bzr log -n 0 [21:08] That won't tell you anything about pending merges. [21:08] d'oh! [21:08] There's no direct way through the UI. You'd have to get your hands on the revid's and go from there. [21:08] qlog does it [21:08] Oh, really? That's nifty. [21:08] I use it so much, I didn't think that regular log wouldn't [21:09] though status -v will show you the commit messages of pending merge parents [21:09] Well, it shows you something like log --line. But that just shows you the first handful of words. [21:11] * fullermd adds an entry to his "cool stuff about qlog" mental list. [22:16] what's the proper way to import files from a branch so one can merge between the two without the history? [22:25] Is there a command that i would use to view all the changes made in previous revisions to a particular file showing the lines changed in the file? [22:27] ubuntujenkins: bzr log -p /path/to/file [22:28] thanks micahg [22:33] So guess what I learned today that I didn't know before [22:33] I learned that switch first looks relative to where the branch you already have checked out lives [22:33] what's the proper way to import files from a branch so one can merge between the two without the history? [22:36] ...cp? [22:48] Kilroo: that's what I was thinking, but I was worried about th efile Ids [22:48] *file [22:53] micahg: I don't know of any meaningful way to merge without involving the history...if you don't want the history I'd think you'd just write/overwrite the files and commit. [23:00] Hey people, I was wondering if `bzr up` supports some kind of switch to make it pull unauthenticated. It seems it will always try bzr+ssh if I have a `bzr whoami`. [23:01] On a lp-branch that is. [23:50] ikanobori: lp: URLs are always resolved to bzr+ssh if you have done bzr launchpad-login [23:51] 'bzr whoami' isn't involved at all. [23:53] spiv: Thanks for the clarification.