[00:00] Hi [00:01] I'm trying to update my checkout and I get a "bzr: out of memory" error.. any ideas how to solve this? [00:15] GungaDin, tell me more [00:15] do you get a traceback in ~/.bzr.log? [00:16] is the tree unusually big or the machine unusually small? [00:16] perhaps both. [00:16] it's in a virtual machine with about 1G [00:16] of ram [00:59] lifeless, question on subunit.... can "test: A\ntest: B\nsuccess: B\nsuccess: A" be valid? (e.g. executor is executing tests in parallel" [01:31] stewart: otp [02:38] stewart: hi [02:38] that B will be ignored [02:39] stewart: to do parallelism, feed the streams through a demux (e.g. the one in testr, which has its source code in testtools) [02:39] lifeless, ahh... cheers. [02:39] stewart: (think about write clipping etc, even if it 'was' ok, a single pipe won't do the right thing [02:40] even with line buffered files, if you exceed a page in size for a single backtrace... [02:50] stewart: ^ [02:51] stewart: if you're parallelising drizzlet, for instance, consider using testr (apt-get install testrepository) - it can track fast/slow tests and give you equal partitions [06:24] hello all, hellaustralia ! [06:25] * fullermd double-checks his hemisphere. [07:16] hello vila [07:16] poolie: hello ! [07:17] I'm freezing 2.5b2 right now [07:17] it's kinda cold here too [07:18] hehe [07:18] We have a nice late summer here (crossing fingers) [07:21] vila is bug 82555 the same as bug 242175? [07:21] Launchpad bug 82555 in Bazaar "Merging to an empty branch doesn't work" [High,Confirmed] https://launchpad.net/bugs/82555 [07:21] Launchpad bug 242175 in Bazaar "Better error message when merging into empty branch" [High,Fix released] https://launchpad.net/bugs/242175 [07:22] Such a hard question so soon in the morning ? /me looks [07:24] poolie: possible, can't say for sure without digging, I asked Aaron about them (IIRC) at the time but I can't find his answers there [07:28] vila it's not a big deal [07:29] i just thought i'd empty the new bug queue [07:29] poolie: great ! I had it on my radar but only triaged some of them last week [07:31] 21 is enough i can feel pleased for getting them done [07:31] but few enough i can actually get them all done today [07:53] argh, news entries added for 2.5b1 instead of 2.5b2 :-/ [07:57] hey poolie, i realized I forgot to say hello today :) [08:00] hi there jam [08:00] how do I move some uncommited changes from one pipe to another in a pipeline? [08:00] oh, maybe I can shelve/switch/unshelve? [08:01] hmm, no [08:01] morning all [08:02] oh, no, I just messed the shelve up the first time somehow [08:09] idnar: there are some rough edges when moving this kind of changes from one branch to another, filing a bug with your actions and why you didn't end up with the desired result can help us fix them (the rough edges, not your actions ;) [08:12] vila: as far as I can tell, I ran into a bug with bzr shelve's interactive change selection [08:12] absolutely nothing to do with pipelines or switching branches [08:13] filing a bug report now [08:13] or, rather, trying to reproduce now [08:13] *facepalm* [08:14] okay, so I think the original problem was just user error [08:14] although the output from bzr shelve is confusing, so I'm still going to report that [08:14] but now I found another bzr shelve bug [08:23] filed #868974 and #868976 [08:24] ubot5: tells us more about bug #868974 and bug #868976 [08:24] Launchpad bug 868974 in Bazaar "Confusing output from bzr shelve for the addition of a file" [Undecided,New] https://launchpad.net/bugs/868974 [08:24] Launchpad bug 868976 in Bazaar "Traceback trying to unshelve in empty branch" [Undecided,New] https://launchpad.net/bugs/868976 [08:24] vila: I am only a bot, please don't think I'm intelligent :) [08:24] ah, I forgot to say "bug" I guess [08:24] ubot5: thanks nevertheless [08:24] vila: I am only a bot, please don't think I'm intelligent :) [08:24] heh [08:24] good bot [08:33] the second one Parth ran into a while back, and I see that some other people have as well [08:35] and yes, the output of the first makes perfect sense to me because I understand all the bits, but I can see how it's confusing [08:39] poolie, jelmer, mgz, RIddell, jam: RM.takes_social_lock(lp:/bzr) for at most 2 hours, please don't land there (the source is already frozen and your landing will be wrong anyway. I'm running 'make check-dist-tarball' before submitting to pqm) [08:41] vila: have you merged up 2.4 yet? [08:41] because that would be useful [08:41] but... I guess isn't the end of the world if you didn't [08:43] mgz: oh, if you want me to talk about that ... :) [08:43] mgz: yes I did, small conflicts easy enough to resolve [08:44] mgz: but in the general case, it's easier for the dev landing fixes in the previous releases to merge up to trunk, if conflicts occur, he is the one with the best knowledge to handle them [08:44] mgz: I've added a note in releasing.txt about doing the check nevertheless [08:45] cool, thanks vila. [08:46] make check-dist-tarball succeeded, submitting to pqm, social lock taken [08:46] mgz: my pleasure ;) [08:48] poolie: regarding lazr/restfulclient while running check-dist-tarball, I usually ignore http://paste.ubuntu.com/703271/ as harmless, I never dig that, I've seen related discussions (AIUI) about it, do you know if doing a new release will solve it ? [08:54] jelmer, re bug 868981, is there any point filing a memory usage bug? [08:54] Launchpad bug 868981 in Bazaar "Failed to branch git repository (invalid record 0x03)" [Undecided,New] https://launchpad.net/bugs/868981 [08:58] vila, i think that noise is caused by https://bugs.launchpad.net/ubuntu/+source/lazr.restfulclient/+bug/796992 [08:58] Ubuntu bug 796992 in lazr.restfulclient (Ubuntu) "pth file overrides pythonpath" [High,Triaged] [08:58] i don't understand why that code is there and the bug is not fixed so merely doing a new release will probably not help [09:00] poolie: ha, right, yeah, that's the bug I had in mind, thanks, I'll subscribe [09:03] poolie: yeah, it shouldn't be trying to load everything into memory [09:04] poolie: you landed on bzr.dev :-/ That won't be included in 2.5b2 [09:07] I think it'd been sent before you said vila. [09:08] mgz: yes, but after I said I was freezing :-/ I can't check everything everywhere *and* freeze :-( [09:14] poolie, mgz: no big deal, bug mark fixreleased in 2.5b3, lp:bzr history will disagree but the tarball is authoritative and doesn't include the fix, I'll open 2.5dev3 now [09:15] social lock still held [09:22] sent [09:22] social lock released. Waiting for the current submission to succeed will be a good idea though [09:24] 2 hours between announcing I was freezing and releasing the lock, probably the fastest release I ever made despite having to merge 2.4 and fix the news [09:24] if the social trick doesn't work, we'll have to find another solution [09:27] freeze announce for 2.5b2 sent, for the benefit of packagers and build installers present here: the tarball has been uploaded, you can't push the build button (I know some buttons are harder to push than others ;) [09:27] s/can't/can/ [09:29] vila: thanks for the heads up [09:29] and good job on the release [09:29] having PQM run in 30 minutes certainly helps [09:30] yup, it's a direct factor for the social lock [09:30] duration [09:31] ugh, poolie, I accidentally left the ec2 instance running after the last build. I wonder if there is something we could do to help me remember. [09:31] I usually shut it down same-day. [09:31] Maybe a cron script that sends a daily email? [09:32] could be good [09:32] can you schedule a shutdown for 24h in the future when you start it? [09:32] poolie: I don't see any way to do so, do you know of one? [09:33] poolie: http://www.cyberciti.biz/tips/schedule-windows-server-to-reboot-or-shutdown-automatically.html ? [09:33] I'm a little hesitant to do it via 3rd party tools [09:34] this one might work: http://www.computing.net/answers/windows-2003/schedule-shutdown-the-server/5216.html [09:34] just set up the instance to always shutdown at midnight my time. [09:34] so if it is "up" it gets stopped [09:38] jam, i haven't done it for a while but i thought there was a built in option [09:38] poolie: the second link tells how to set up a scheduled job that runs 'shutdown.exe' [09:39] looks like it will work, I'll give it a shot. [09:39] yeah, from the command line, i thought so [09:42] vila: we have 'lp:bzr/2.5' is there a reason it doesn't have bzr-2.5b2 tag in it? [09:43] we shouldn't have lp:bzr/2.5 [09:43] hmmm... I dont't see one in lp:bzr either [09:43] vila: https://code.launchpad.net/bzr/2.5 is actually pointed at trunk [09:44] so it exists, but for now it is just the trunk branch [09:44] just an *alias* for trunk [09:44] oo, aix buildbot offer [09:44] regardless, I don't think we have bzr-2.5b2 available as a tag to build from [09:44] so I can't actually build the windows installers easily [09:45] I suppose I can pick a rev instead of a tag [09:46] jam: thanks for the heads-up, looks like I missed a step [09:47] vila: do we have a patch pending? We could get it to merge trunk and add the tag [09:48] vila: I have one, I'll go do the tag dance. [09:48] jam: sent [09:48] Do you want your rev or PQM's rev to have the tag? [09:49] jam: I just sent a submission to fix that [09:49] vila: sure, though I don't see it in PQM yet [09:50] shouldn't be long now [09:50] here it is [09:51] there it is [09:53] oops, apparently I didn't search hard enough for dups [09:54] Oh, frew. It just occured to me to wonder "Jeez, why haven't I seen any bzr commits in a month?" [09:59] yeah, you need to join a new team fullermd [09:59] No, apparently the last round of PQM changes changed how the emails were generated. [09:59] So they fell through my existing filters and wound up bitbucketted. [09:59] ah. [10:00] At least, that's my best guess... [10:01] you have PQM telling you about bzr commits? [10:01] The -commits list. [10:01] bazaar-commits.lists.canonical.com, right [10:02] fullermd: just curious, I didn't have issues here, what filter were you using ? [10:02] Which makes it half-suck, 'cuz it means I don't even get to work up a good blood pressure overload about LP's emailing over it... [10:02] Throwing away everything that wasn't from pqm@pqm.ubuntu.com. [10:03] * fullermd waits for the next submission to run through to try and figure out how to discriminate now... [10:04] meh, correction, I don't get them anymore either since 2011-09-07 :-/ [10:04] oh, I think I know, probably due to the migration to a new hardware [10:05] You mean it's not actually sending them anymore? [10:06] Well, that makes me feel better about my filters anyway... :p [10:06] fullermd: seems like it, thanks for the heads-up [10:07] not that I read these emails with a great attention but it's a good heart-beat under some circumstances [10:08] I use them to keep track of "all the back-branches are merged to .dev, time to pull again" :p [10:08] fullermd: reported, fix seems easy, should be back soom [10:08] soon [10:15] night all [10:16] night poolie [10:19] poolie: night [10:22] night poolie [10:39] I'm trying to decide how well "Precise" works as a release name. "We need to get this into Precise" doesn't seem to fit as well as backporting it to hardy and lucid. [10:39] Maybe it is just repetition that makes the others ok [10:42] They all sound equally weird to me, if that helps :p [10:43] I always find myself waiting for the next line when people end sentences with adjectives like that... [11:23] bug 84822 and the linked debian bug are straight up fixed by the inclusion of the bash-completion plugin, no? [11:23] Launchpad bug 84822 in Bazaar "bash completion should use shell-complete" [Medium,Confirmed] https://launchpad.net/bugs/84822 [11:35] vila: can we land stuff again?: [11:35] jelmer: yup [11:36] 11:22 social lock released. Waiting for the current submission to succeed will be a good idea though [11:36] I forgot to prefix my msg though [11:36] mgz, Riddell: go ! Land ! :) [11:36] * mgz swoops down [11:37] * fullermd chooses to Sea instead. [11:37] I want at least one more babune run with the current trunk before landing my cleanup testcases branch [11:38] mgz: looks like you're right about bug #84822 [11:38] Launchpad bug 84822 in Bazaar "bash completion should use shell-complete" [Medium,Confirmed] https://launchpad.net/bugs/84822 [11:39] mgz: hehe, I wasn't reminding you about that, just making sure you knew I wasn't locking bzr.dev anymore ;) [11:39] jam, mgz: speaking of babune, freeBSD and OSX failed, different tests than gentoo yesterday [11:41] who've we got that can mark debian bugs fixed? jelmer? [11:41] vila: for this failure: http://babune.ladeuil.net:24842/view/OSX/job/selftest-osx-10.6/lastCompletedBuild/testReport/bzrlib.tests.per_interrepository.test_fetch/TestInterRepository/test_fetch_parent_inventories_at_stacking_boundary_smart_old_InterDifferingSerializer_RepositoryFormatKnitPack1_RepositoryFormatKnitPack6RichRoot_/ [11:41] the patch should have just landed in bzr.dev [11:42] 6197 [11:42] the other one I have to think about [11:42] I think I know a fix [11:43] mgz: Everybody can mark debian bugs fixed [11:45] huho babune consuming 300% CPU without any job running, bad stuff [11:45] Isn't that what java stuff is _supposed_ to do? [11:46] fullermd: right. [11:46] fullermd: but they don't do it usually :) [11:47] jam, mgz : Are you querying unusual stuff ? [11:47] vila: i'm not doing anything on babune atm [11:47] I did go look at the tests a few secs ago [11:47] including browser queries I meant [11:48] nothing in the logs, scary... [11:49] CPU is back to normal but something is still reading at 12MB/s [11:49] done [11:49] weird [11:51] vila: I'm going to do a test run on OSX, in case this is specific to osx [11:52] (specifically, we .accept() and then .close() right away, which OSX might trigger as an error on the client) [11:52] but I think that test has passed on OSX before, but I'll check [11:52] vila: there isn't a "selftest-subset-osx" am i just missing it? [11:53] s/osx/macadam/ hysterical raisins [11:54] http://babune.ladeuil.net:24842/view/OSX/job/selftest-osx-10.6/lastCompletedBuild/testReport/bzrlib.tests.per_interrepository.test_fetch/TestInterRepository/test_fetch_parent_inventories_at_stacking_boundary_smart_old_InterDifferingSerializer_RepositoryFormatKnitPack1_RepositoryFormatKnitPack6RichRoot_/history/? is... quite weird [11:54] * mgz touched nothing babuney [11:54] * vila blames gremlins [11:55] The whole "don't feed them after midnight" instruction was frustratingly unclear about the effect of timezones and leapseconds... [11:56] fullermd: WHAT ? It's not UTC ??? OMG [11:57] Well, is it UTC, or UT1, for instance? [11:58] NFC or NFD ? [11:59] * fullermd is pretty sure "NFC" contributed significantly to the damage caused by gremlins :p [11:59] vila: sure, the specific failure of that test was a timeout, but as you can see the time spent is *all* over the map [12:00] 5s, 2 min, 4s, 2m11s, 2m38s, 4.3s, 1m28s [12:00] now *that* is variability [12:00] it's so huge I'd be surprised if there isn't a bug behind that for quite some time [12:02] but the test succeeded... I can imagine it was starved by other threads... but that implies quite a sucky scheduler [12:03] oh, wait, mgz, wasn't there a bug about testtools/subunit outputting bogus timestamps ? [12:04] er, hm? [12:04] don't think I've seen it. [12:04] vila: at one point it was mixing the timestamps from multiple streams [12:04] but that wouldn't be strictly 'bogus' [12:04] yeah, something like that === yofel_ is now known as yofel [12:11] mgz: I lost track about bug 807032, is there something I should do ? [12:11] Launchpad bug 807032 in Bazaar 2.4 "blackbox.test_branch.TestBranch.test_branch_broken_pack can (and did) fail ramdonly on pqm" [High,In progress] https://launchpad.net/bugs/807032 [12:12] wow, nice touch ubot5, indeed, only the 2.4 bugtask is relevant here [12:13] eeerk ! lunch ! [12:13] oo, good idea vila [12:14] vila: you should cherrypick the fix back to 2.4 [12:14] (as ubot5 told you) [12:16] ugh, jelmer is missing [12:16] his version-info change is actually incorrect [12:16] it *doesn't* change the revision that is analyzed (the working tree) [12:16] it only changes what revision gets *reported* [12:16] which is pretty badly broken [12:16] (So it will say the files are at state X, but the Revision is at state Y) [12:21] Riddell: regarding https://code.launchpad.net/~benoit.pierre/bzr/ui.confirm/+merge/77826 , what's the best practice for i18n ? [12:21] Riddell: more precisely [12:22] good poke vila, getting Riddell to look at it is sensible [12:22] Riddell: we have a list of choices to translate with the constraint that a shorcut should be available for each choice (so unique) [12:23] Riddell: what do translators prefer ? A single string with all choices ? Separate strings but somehow (for what value of somehow ?) grouped so they can respect the constraint ? [12:24] jelmer: I think you missed my earlier comments. Your fix for bug #238705 isn't quite correct [12:24] Launchpad bug 238705 in Bazaar "version-info command should take branch argument and -r option" [Low,In progress] https://launchpad.net/bugs/238705 [12:24] changing _get_revision_id just changes what revision is reported [12:24] but doesn't change what tree is analyzed [12:25] jam: Sorry, I did indeed. I just saw Vincent's approved message [12:25] yeah, I sent it after it was merged [12:25] I didn't see the proposal earlier [12:26] jam: it does seem to influence the tree here, but perhaps not for all formats [12:26] charis:~/src/bzr-svn/trunk% ~/src/bzr/version-info-args/bzr version-info -rtag:bzr-svn-1.0.0 [12:26] revision-id: jelmer@samba.org-20090924110140-gl7z957rc35m0csc [12:26] jelmer: sure, but that is only the *revision* that is reported, not the tree state [12:26] you probably have to pass --include-file-revisions [12:26] or --check-clean, etc. [12:26] the date and revno that's reported is also from 2009 [12:27] I was originally going to say that "--check-clean" shouldn't be allowed with --revision [12:27] jam: Ah, hmm [12:27] and then tracked it down to see that file revisions, etc wasn't touched [12:27] I'll follow up to your comment [12:27] and I'm not sure about "--revision-history" [12:28] hi, i would like to ask you guys if anyone can comment on the state of the bzr plugins for IntelliJ IDEA - are they up to date and covering current bzr features, or is there anything missing? [12:28] rawtaz: I haven't heard much about them for a while, so they are probably a bit out of date [12:28] i see bzr4idea is 2009-07 the latest, and Bzr4IntelliJ is from 2011-02 [12:32] jam: I need to go into the city for a bit, will follow up once I get back. [12:32] k [12:33] thanks jam [12:43] vila: I don't think it matters much for translators if it's all separate or in one string [12:44] I think translators will want a comment to know the restrictions but we don't current support comments on our translations [12:44] Riddell: how do they know they are related on must define different shorcuts for each ? [12:44] s/on/and/ [12:44] vila: we should support comments on translation [12:44] Riddell: the menus are likely to have the same requirements no ? [12:45] hmm, may be not, may be the first (or last) shortcut in a menu is taken into account... We can't afford that in the general case... but may be waiting for bug reports will be enough ? [12:46] >-/ [12:46] what menus? [12:46] any application menus [12:46] in GUIs? Qt is usually smart enough to sort out the shortcuts for you [12:47] hehe, bad choice vila, try again [12:47] Riddell: the mp I referred proposes a special char to identify the shortcut, no smarts ;) [12:51] alternatives = '&yes\n&No' so the ampersand is used for the shortcut? [12:51] yup [12:51] that's the same as GUIs so most translators will know about it already [12:52] so better stick with a single string ? [12:52] I don't think it matters either way [12:52] single string is fine [12:53] if char == 'y': that isn't working with translations though [12:55] yup, the proposal returns an index but I raised the issue that requiring the callers to get back the shortcuts untranslated is awkward. [12:55] shouldn't it be smarter and know what the shortcut char is for the option rather than hardcoding 'y'? [12:55] Either the callers should use the indices directly or we should find an easier way [12:58] Riddell: the issue with using the shorcuts in the caller is that we want to keep using the english ones [13:00] Riddell: but if it's too hard I'd rather use indices (or constants ?) instead or just a simple string listing the shorcuts alongside the choices themselves... bah, shelve have an optional 'e' that will break that too... [13:11] `bzr clean-tree --force --ignored -q` is a bit annoying to type [13:15] bzr alias ? [13:15] Just needs a M-x in the middle somewhere. [13:17] :) [13:21] the errors in are because the branch that was landed to check the version of testtools and use different assertions is busted in some respect [13:22] ok [13:22] so kind of related to the bug as it may blow up if pqm is upgraded ? [13:24] yup, dependencies suck. [13:25] mgz: meh, I asked the question in the wrong channel 8-) [13:25] mgz: and you replying here didn't help me realize :) [13:26] but due to the magic of highlights I saw it anyway [13:27] hehe === zyga_ is now known as zyga-afk [14:19] jam: do I need to do something extra to turn on more cython warnings? [14:20] because just running build_ext (in a clean tree) isn't complaining about uninitialised variables [14:21] maybe they reverted a change on trunk? [14:21] * mgz looks at changelog [14:24] maybe: [14:29] ...seriously, their only changelogs are on their wiki? [14:29] and for 0.15.1 their release notes consist of a link to trac and a link to github [14:30] that looks like the answer though, frivolous warnings were disabled [14:32] compiz, 1GB is just too much, give some back or I'll kill you [14:32] compiz won. [14:33] the OOM killer got vila instead. [14:40] vila, hi, not sure if you're getting mail for https://code.launchpad.net/~jml/udd/symbol-import/+merge/77312 [14:42] james_w: I think I do, but I opened the page yesterday and missed your review :-/ [14:42] james_w: oh, you did review more, wth ? [14:42] I think it may be that you got a notification through being asked to review via a team [14:42] when someone does that review LP no longer mails that team [14:43] crap [14:43] this bites me all the time, as all you see in that case is a request for you to review, and you don't see that someone else has done it [14:43] and yes, I've filed a bug [14:44] james_w: subscribed, thanks for the heads up [15:41] hm, tree transforms are hard, I'll go back and look at cython warnings instead [15:41] I have two branches that do not currently share history that I want to combine. Should I branch one into a temporary subdirectory of the other, "bzr join" that, and then "bzr mv" everything to its proper place? Or is there some neater way? [15:44] oh wait, I guess "bzr join" doesn't commit, so I can just do the join and the following moves and merging of toplevel files in one commit? Does that make sense? [15:44] I should just try instead of bugging you folks :) === beuno is now known as beuno-lunch === zyga-afk is now known as zyga [16:26] thx vila for #861472 [16:27] briandealwis: my pleasure (your timing was perfect ;) Feedback welcome ! [16:29] The only thing that springs to mind, since you're looking at the config format, is that it would be nice to have some way to override variables on a per-command basis. For example, to cause log_format=line for pull only. I have a datetime_format var for tiplog, but I call it tiplog_datetime_format to ensure it won't stomp on any other toes === beuno-lunch is now known as beuno [16:31] briandealwis: option expansion may address some cases (but it's not fully there yet): pull.log_format = {log_format} [16:32] that'd be very useful [16:34] briandealwis: you can also use aliases [16:36] That's what I do now. Doesn't work when you execute a command remotely through ssh or within an editor though [16:36] briandealwis: but abusing -O will render all other config files useless so... time will tell [16:38] briandealwis: also, if you start introducing config options, the stack based design have a registry so you're either /guaranteed to have your own option/ or /your plugin won't load/ [16:40] vila: ok… I think. You mean I'll *have* to put something like 'tiplog.datetime_format = {datetime_format}' somewhere or else the plugin won't load? [16:41] briandealwis: no, you have to config.option_registry.register(Option('tiplog.datetime_format', ....)) [16:42] briandealwis: EOD here, but feel free to ping tomorrow for more [16:42] ok [17:18] re: bug #838469, should improvements to mini-tutorial be submitted for released versions as well, or will they only be accepted for bzr.dev? [17:18] Launchpad bug 838469 in Bazaar "Mini tutorial doesn't explain repository directories" [Low,Confirmed] https://launchpad.net/bugs/838469 [17:19] good question. [17:20] also, do we have history horizons (aka shallow checkouts) yet? [17:23] heh, "Say a project FOO is running for 30 years, accumulated 100 000 revisions and the repository has grown to 1GB1." [17:23] also known as 'emacs' :) [17:41] mathrick: there are stacked branches, and it's possible to do commits on top of stacked branches in newer versions of bzr [17:41] jelmer: yes, I (re)discovered that a bit after I asked === deryck is now known as deryck[lunch] === deryck[lunch] is now known as deryck === med_out is now known as medberry [22:27] How can bzr avoid using hashes for commits? I don't get it, heh. [22:33] JordiGH: I'm not sure I follow, avoid hashes where? [22:34] Hm, this doc gave me the impression that bzr didn't use hashes, only revision numbers: http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html [22:35] in the UI, yes [22:35] JordiGH: it uses globally unique identifiers to identify commits too, but those aren't generally shown in the UI [22:35] in the underlying trees, no [22:35] Does "UI" mean "GUI"? [22:35] any user interface [22:35] if you type "bzr revno", it's a type of user interface too [22:36] e.g. "bzr log --show-ids" will show the UUIDs too [22:36] Ah. [22:36] I don't know, it sounds like revision numbers would cause a lot of problems for a distributed workflow to the point of being useless. [22:37] Is there some clever solution here? [22:37] JordiGH: in practice they work reasonably well [22:37] JordiGH: yes, you always refer to revnos in the context of a specific branch [22:37] JordiGH: if I saw r4343 of trunk, that has meaning [22:37] which is how you work in practie [22:37] *practice [22:38] I don't see in "bzr" a concept of clones like in git or hg. What is a "branch" in bzr? Is it a clone? A path in the DAG? A ref? [22:38] When you delete a "branch", what do you delete? A ref? A filesystem tree? The entire repository? [22:39] what are you trying to accomplish by asking that? [22:39] Trying to understand bzr. [22:40] read the user guide, it has more info than you can wish for! [22:40] bzr has really solid docs [22:40] "branch" means something very different in hg and git. I want to know what it means in bzr. [22:40] http://doc.bazaar.canonical.com/en/ [22:40] Can I see a bzr definition of "branch"? I don't see it in the docs. Seems to be a concept you have to osmose instead. [22:41] branch is a DAG with a specified tip [22:41] So if I delete a branch, I delete a whole path in the DAG? [22:41] depends on where the revisions are stored [22:41] Wait, there is more than one DAG? Or is it the same DAG, just disconnected? [22:42] Can a repository have more than one DAG? [22:42] bzr branches might have their working trees and their repositories physically separated [22:42] JordiGH: a repository *is* a DAG. But it need not be connected, no [22:43] a branch is, in practical terms, a tip plus a bunch of metadat [22:43] a [22:43] Uhm. [22:43] So it's a ref? [22:43] you need to ask jelmer, he understand git terminology :) [22:43] but I think so, yes [22:43] A tag? A bookmark? Just metadata, like in git? So when you remove a branch, you only remove metadata? [22:44] Can I see a bzr definition of "branch"? I don't see it in the docs. Seems to be a concept you have to osmose instead. <- [22:44] depends on where you stored the repository. If it's a standalone branch, then it will have its data stored in the same dir as its working tree, so if you delete this directory (which is what bzr would call "removing a branch"), you will kill these revisions as well [22:45] if it used a shared repo, which is the recommended setup for large-scale usage, then no, it won't touch the stored revisions [22:45] wgz: Thanks. [22:45] Okay, a branch is a path in the DAG. I'm ok with this. [22:45] Not like git. [22:46] actually multiple paths potentially, since there's no limit on the number of parents a revision can have [22:46] Right, a tip plus all its ancestors. That's a branch, right? [22:47] yes [22:47] JordiGH: git's branches are somewhat similar to bzr's lightweight checkouts [22:47] bzr's branches sound more like hg's branches. [22:48] there's a plugin emulating git-style (aka "collocated") branches with a shared repo + checkouts [22:48] No, I don't want git. :-) [22:48] I just want to understand bzr. [22:48]