pooliehi all00:50
wgzack, I need to be in bed if I'm gonna make tomorrow morning00:51
pooliesleep well :)00:51
=== maxb_ is now known as maxb
=== RickCogley_ is now known as RickCogley
poolielifeless, did you see http://giovanni.bajo.it/2011/09/golomb-coded-sets/05:51
lifelesspoolie: interesting!06:15
poolieit's a very elegant series of steps06:22
pooliei'd like to have a chat with you some time this week06:28
AuroraBorealishttps://bugs.launchpad.net/bzr/+bug/847388 i believe this bug is 'solved', but i dunno how to confirm it (that it works on windows/mac)06:29
ubot5Ubuntu bug 847388 in Bazaar ""gpg: cannot open `/dev/tty': No such device or address" on Ubuntu when signing commits" [Medium,In progress]06:29
poolieAuroraBorealis, solved how?06:30
pooliewe pass the option, or we give it a tty, or  gpg stopped complaining?06:30
AuroraBorealismy 'change' in that branch is literally just adding --no-tty to the gpg arguments06:30
lifelesspoolie: sure, that would be great. At 1730 my time we start operation cynthia-has-to-go-to-bed, but other than that I'm free whenever my google calendar thinks I'm free06:30
poolieoh you're mark?06:31
AuroraBorealisthat makes it so it WORKs on ubuntu (which was the only OS that had problems), and it still works as intended on mac/windows06:31
AuroraBorealisyeah. i should probably use that name here xD06:31
poolieif you want to only land it on trunk i think you can just put it in06:31
poolieif it's intended for 2.5 we have to be quite careful06:31
AuroraBorealisi dunno how to 'put it in' or if its indended for 2.506:32
AuroraBorealisit pretty much makes bazaar explorer unusable if you are signing commits (since you can't commit with it)06:33
poolieso you're prettysure that has no (harmful) effect on windows?06:36
pooliei don't expect it would06:36
AuroraBorealisi tried it06:36
poolieoh, great06:36
AuroraBorealisi just downloaded my branch and ran the bzr python file, tried creating a repo and commiting with the signing06:37
poolieok so you should just click 'propose for merging' on https://code.launchpad.net/~markgrandi/bzr/gpg_devttynotfound_fix06:37
poolieand choose lp:bzr/2.5 as the target06:38
AuroraBorealisi mean i 'hope' it worked, it commited and didnt say any errors, i dont think there is a way yet to actualy verify the signatures =P06:38
AuroraBorealis~bzr-pqm/bzr/2.5 that it?06:39
pooliethat's it06:39
poolieyes, http://doc.bazaar.canonical.com/beta/en/user-reference/verify-signatures-help.html06:39
AuroraBorealishmm needs some weird package installed on windows06:40
AuroraBorealisi'll try it later06:41
pooliei would be reluctant to put it in after the last beta unless it was well tested across platforms06:41
pooliereally only windows is a concern though06:41
poolielifeless, ok, 12nz tomorrow?06:44
mgzmorning all!07:39
vilamorning mgz et al.07:41
pooliehi mgz, hi vila07:42
pooliemgz i replied on https://bugs.launchpad.net/bzr/+bug/85183407:42
ubot5Ubuntu bug 851834 in bzr (Ubuntu) "bzr crashed with error in _curl_perform(): (35, 'gnutls_handshake() failed: A TLS packet with unexpected length was received.')" [Undecided,Confirmed]07:42
mgzpoolie: thanks07:43
pooliei'm not sure it will help but that's what i'd try next07:55
wgzis the kind of thing I was after07:57
pooliewgz,  then you can open the pcap file in wireshark08:02
pooliewith which jelmer is an expert08:02
wgzthe use of jelmer is also something I'm in favour of08:03
jelmer*ahem* :)08:06
vilajelmer: so, re-reading http://docs.python.org/library/ssl.html?highlight=cert_optional#ssl.CERT_OPTIONAL09:17
vilajelmer: certificates will be required from the other side, i.e. required from the server by the client09:17
vilajelmer: that's about the server certificate not about the client root certificates09:17
jelmervila: ah, ok09:18
jelmervila: so I guess we'll need a new option after all09:18
vilawell, a new value for the option will do in the interim09:19
vilawhat I want to avoid is people setting it in their config file and don't use the default when we change it09:19
vilas/I want/I'd like/ ;)09:19
mgzsomething as dumb as ssl.cert_reqs default being 'none' on win and osx and 'required' otherwise would be okay for now09:34
farbluemorning everyone :) We are evaluating switching from svn to an alternative vcs and can't find any info on whether bzr has support for something similar to svn's --record-only as a way to prevent a commit being merged down from branch to trunk09:56
PengWhat's --record-only?09:58
farblueit is used during a merge to mark the merge as having been done but without actually applying the patch09:58
farbluefor instance, we have a release branch and trunk and we might have made a change on the release branch we don't want in trunk (a bug that's been fixed as part of larger changes in trunk but then patched in the release branch quickly to prevent problems)09:59
farbluewe want to merge the release branch back to trunk to prevent regressions but we don't want that particular commit to be merged back09:59
PengYou can bzr merge it and then do "bzr revert ." -- note the period -- to throw out the physical changes but leave the merge metadata.10:00
pooliethanks Peng10:00
poolienight all10:00
farblueok, that's a reasonable option10:01
farbluea little less intuitive than the --record-only svn option but at least there is a way :)10:01
farblueany other ideas? any plugins that might help?10:02
farblueJust gathering support for bzr over other options you see :) Need to put forward a good case :)10:02
pooliefarblue, that's how it's done at the moment10:09
vilamgz: works for me, will file a mp doing that10:09
poolieyou could fairly easily patch bzr to add a --record-only if you want10:09
farbluegood point :)10:09
farblueI see the alternative way to do it might be to add a metadata tag of some sort to the commit so that when anyone tries to merge it it just updates the merge tracking and doesn't apply the patch10:10
farblueanyhow, thanks :D10:11
=== yofel_ is now known as yofel
LarstiQvila: do you have any numbers for how much an improvement the config caching is?10:39
vilaLarstiQ: I will have them shortly for the whole test suite but you can look at the impact on the hpss calls in the revision I recently landed10:40
vilaghaa, unity 2D has some rough edges :-/10:40
mgzsharp edges, being a planar surface I'd expect.10:41
LarstiQvila: ah right. About 1 to 2 less hpss calls in 10 places10:42
vilaLarstiQ: roughly the actual implementation does: to get an option value: read/parse the config file[s] where the option can be defined, to set an option: read/write the config file10:43
LarstiQmgz: ah hmm, but the regularity of the edge might be pretty bad10:44
LarstiQvila: and within a lock it will only read once?10:44
vilaLarstiQ: the new implementation will read each file once and cache its content, modifications are cached and flushed when the lock is released, read the file (for concurrent updates), write it10:45
vilaLarstiQ: almost yes10:45
vilaLarstiQ: that is, without modifications, it's read only once10:45
vilaLarstiQ: if there is at least one modification, it needs to be read again (to protect potential modifications made by other processes) and write once10:46
LarstiQvila: right.  So then we'd expect more benefit on longer lived operations10:46
* LarstiQ nods10:46
vilaLarstiQ: the main target is to allow reading once for all options (the fallouts are in the tricky update process that requires a lock)10:47
vilahmm, in fact the unity 2D model when switching wrokspaces is in some way *better* than the 3D one: all desktop are presented with all windows 'exposed' so when you switch to a different workspace you can directly select the windows you're interested in10:49
vilait's worse if the windows you're interested in is already visible of course...10:49
vilamgz, jelmer: https://code.launchpad.net/~vila/bzr/929179-default-ssl-certs/+merge/93177 is up for review10:50
vilamgz: may be you should include that for the 2.5b6 windows installers and get them out of the door :)10:50
vilamgz: also see bug #932647 for more info I gathered on the windows native calls10:51
ubot5Launchpad bug 932647 in Bazaar "native root certificates should be supported on windows" [High,Confirmed] https://launchpad.net/bugs/93264710:51
farbluehi again :)11:07
farbluea quick question about revision numbers - I understand the incrementing number and the . separated numbers for branches11:08
farbluebut are these global for the repo or are they specific to my copy of the repo?11:08
farbluee.g. if i refer to revision 1234 will it be the same revision as rev 1234 on a colleague's machine?11:09
quicksilverif they're looking at the same branch11:10
quicksilverthen they'll have the same numbers.11:10
farblueI'm assuming 'trunk' here as there are no dots in the number11:10
quicksilverif you like revision numbers (we do!) then you will want to make sure you don't "push" onto one of your main trees11:10
quicksilver...from a different branch11:10
quicksilverpushing from a different branch can pivot the revision numbers.11:11
quicksilverinstead, merge + commit into the branch and keep your revnos monotonic.11:11
farblueso you mean we should merge our work onto the 'trunk' and then push trunk?11:11
quicksilverif you are working on separate branches, yes.11:11
quicksilverif you are just working directly on trunk it doesn't matter.11:11
quicksilverif you *are* working directly on trunk then I recommend a 'bound branch'11:12
quicksilverthat makes it harder to get it wrong.11:12
quicksilver(all your commits go upstream immediately and it complains if you're out of date)11:12
quicksilver(1) small fixes directly on trunk, use a bound branch (2) feature development in separate branches, eventually merged into trunk11:13
quicksilveris the workflow we use.11:13
LarstiQfarblue: you can also set the `append_only` option on trunk11:13
farblueCurrently we use SVN and are looking at alternatives as part of evaluating whether SVN still does what we need. From what I understand so far, we can have bound trunk and bound branches just like svn's way of doing things then we can start to make use of local, unbound branches for local work11:13
farblueappend_only means it won't re-shuffle the revisions, I gather11:14
* LarstiQ nods11:14
quicksilveryes although nothing to stop you also periodically publishing those "local" branches to a central server for mutual code review etc.11:14
quicksilver(under a different name from trunk, clearly!)11:14
quicksilverLarstiQ: thanks, I didn't know about that one.11:15
farbluecool :)11:15
LarstiQ`append_revisions_only` is the correct name according to `bzr help configuration`11:15
=== zyga is now known as zyga-afk
farblueWe refer to revision numbers quite a lot in tickets, in redmine etc. and changing those to manual tags or long sha1 hashes doesn't appeal :)11:17
quicksilveragree farblue11:18
quicksilverso do we11:18
quicksilveralso redmine^Wchiliproject's repo viewer gets confused if revision numbers change.11:18
quicksilverLarstiQ: will it also forbid the occasionally bzr push --overwrite where we really *do* need to change history?11:19
LarstiQquicksilver: yes11:20
mgzyes, but you can flip the config, push, and flip it back11:20
jelmervila: did your RangeFile.read patch land?12:08
vilaI think so12:09
vilajelmer: found another case where it's not enough ?12:09
jelmervila: yeah12:10
jelmerI guess you've only fixed it for the size=-1 case?12:11
viladetails ?12:11
vilawell, I was testing with an import that used size=16384 or something, may be I didn't run it against the last version12:11
jelmerI'm calling read(1024) on a RangeFile returned by HttpTransport_urllib.get()12:12
vilaand ?12:12
vilaI mean, how does it fail ?12:12
jelmerbzr: ERROR: Invalid range access in http://xwax.org/devel/xwax.git/objects/21/6e47cb4d38615f2e3cb306912fc495e0bdc713 at 2: Can't read 1024 bytes across range (0, 157)12:12
* vila blinks12:12
vilathe error is supposed to be raised by a different code path12:13
vilaso either you're not using the right bzrlib or ... something is broken in the whole file detection (which seems weird since it's based on the 200 error code...)12:13
jelmerah, yeah12:14
jelmervila: sorry, pebkac12:14
jelmerI'm indeed using an older bzr version12:14
vilano worries, better safe than sorry12:15
* vila re-runs his test for good measure, blaming unity 2D for making it harder to work with multiple workspaces ;)12:16
farblueCan anyone tell me whether bar has support or a plugin to support token locking or binary (unmergable) content? Subversion has locks, for instance.12:23
farbluebzr* (autocorrect fail)12:23
farblueto help prevent 2 people working on a binary asset at the same time12:24
farbluedoes it work? anyone using it?12:33
Riddellcongratulations jelmer12:53
=== zyga-afk is now known as zyga
jelmerRiddell: thanks, what for ? :)12:56
Riddelljelmer: the canonical spotlight award!12:57
mgzhey, there's a prize and everything. go jelmer.13:00
jelmerwow, thanks! :) I hadn't seen the email yet13:01
GRiDcongrats jelmer13:30
vilacong... ha, I'm late, anyway, just saw it, congrats jelmer ;)15:18
* quicksilver doesn't know what that is, but congrats jelmer anyway :)15:20
vilaquicksilver:hehe, sry, he got some company internal award for being our... dude ;)15:21
quicksilverjelmer++ # dude15:22
jelmerheh, thanks vila, quicksilver :)15:23
mgzI think we ought to make congratulate jelmer day a regular thing15:50
mgzmakes a nice change from why haven't fixed my pet bug yet jelmer days15:50
vilamgz: +115:51
vilajelmer: looks like my review got lost on https://code.launchpad.net/~jelmer/bzr/2a-repo-supports-nested-trees/+merge/89919, dunno what happened, just re-did it16:30
jelmervila: merci bien !16:36
farbluehi all :)16:45
farbluedoes anyone have experience of dealing with 'vendor branches' in bzr?16:47
vilafarblue: we are GPL hackers, we don't sell anything, all branches are free ;)16:48
vilafarblue: joke aside, all branches are equal except when social conventions apply16:49
vilaso a 'vendor branch' is just a branch and how you interact with it depends on your workflow16:49
farblueok, let me rephrase: dealing with developing on top of a third-party source code for which you only see the release versions16:49
vilayou can maintain a vendor branch with its own set of changes and still merge regularly from trunk16:50
vilaoh, you mean the release versions are not under version control at all and you get only tarballs ?16:50
farbluecurrently we spend ages in svn applying the new source over the top of our 'vendor branch'16:51
farblueand it's a pain16:51
farblueof course, once done we can merge the changes into trunk and all is rather easier16:51
farbluebut that initial application of the new source dump over the top of our 'vendor branch' is a real pain16:52
vilayup, the crucial point is to track the releases in a bzr branch that share history with *your* stuff16:52
farblueanyone got experience of how well bzr handles this?16:52
farblueyeah, I mean once we've updated the vendor branch in svn things do work well enough but that initial application of the new vendor code release to the vendor branch working copy is horrible16:53
farbluejust wondering whether life would be easier when using bzr16:53
vilapretty well as long as you can avoid your 'parallel import' nemesis16:53
farblueparallel import?16:53
vilabzr tracks renames by assigning a file-id when a file is first added16:54
vilathere is a catch: if the same file is added independently, it gets a different file-id (it is imported in parallel)16:55
farblueso, like with svn, if a file is renamed we need to go hunting for it and tell bzr that, in fact, this new file isn't new but a rename (i.e. apply the rename first to the old file before then replacing it with the updated version)16:56
vilaif you already have a branch with your stuff, create a new branch from that, untar the upstream source, commit16:56
farbluewon't that then mark the incoming changes from upstream as 'newer' than our changes?16:57
vilawell, ideally you start from the upstream source and create a branch for your stuff avoiding the issue, the trick above is for catching up16:57
vila'newer' depends on when you merge this upstream branch into your trunk16:58
vilaif you maintain the upstream branch separately and always untar there, things will become clearer in the long term16:58
vilafarblue: the best way to understand is to try and look at the result with 'bzr qlog trunk upstream' to see how the branches are related,  when they merge each other, etc16:59
farbluein svn we have a branch for the upstream and then that is merged to trunk. We then develop on trunk (well, feature branches but whatever), making our changes as needed. We do our releases as you usually would etc. For a new upstream release we update the vendor branch to the latest version and then merge this set of updates into trunk, resolving the few conflicts we might have.17:00
farbluedoes this basically sound the same as how you'd do it in bzr?17:00
farbluefine, ok :) For us it is step one - "updating the vendor branch to the latest version" that is the painful bit :(17:01
vilathe caveat is about *starting* the upstream branch17:01
vilareally ?17:01
farbluewell, the projects we are basing our code on tend to get refactored quite often and not released frequently so we have very large differences between upstream releases17:02
farbluea real pain actually17:02
vilawell, it's hard to get VCS benefits if upstream doesn't use VCS...17:03
vilaare you sure you can't access their VCS repo ?17:03
farbluewell, for Roundcube we are considering it but they've also got better at releasing more frequently17:03
farbluefor other projects there is no public vas available17:04
vilajava code ?17:04
vilathe only tricky part should be renames, unless you're talking about changes to code that is moved from one file to another17:05
vilafile/dir renames I mean17:05
farbluewell the worst situation for svn is where a file we have modified is renamed / moved in the upstream project17:06
LarstiQfarblue: unpack into vendor branch, and then some combination of bzr add/bzr mv --auto/after?17:06
farbluewhat's the --auto/after stuff?17:07
vilaguess the renames :)17:07
LarstiQfarblue: I'd need to try out the workflow, but I think `unpack; bzr mv --auto; bzr add`17:07
farblueguess the renames? cool :) Even if there has been a percentage of the source changed within the renamed file?17:08
vilafarblue: or more precisely: guess the renames based on the content17:08
LarstiQfarblue: `bzr help mv`  doesn't elaborate too much, but --auto tries to guess renames17:08
vilafarblue: yup17:08
farbluevery useful :)17:08
vilathat could fail if the changes are too broad of course17:08
farbluein many cases it's just a case of a folder having been renamed or similar but svn still hates this17:09
vilabut you can focus on those after most of the trivial ones have been handled17:09
farblueyes, the ability to attempt to guess at renames is very useful17:09
vilaI'm not sure --auto handle dir renames but bzr will track them happily17:09
farbluesounding good :)17:10
vilabasically, if you don't have the VCS history, you have to provide the minimal missing bits17:11
farbluenow I originally considered whether stacked branches would work in this situation and I'm interested to understand why this hasn't been suggested :)17:12
vilastacking is for repos more than for branches, avoid ti if you can ;)17:12
farbluesounds like the advice I give to people enquiring about svn:externals :)17:13
GrueMasterHey.  Semi-noob question.  I have a tree that I maintain on launchpad, and a merge request.  The proposed merge was created by a user that used the source tarball (sans .bzr) and checked into a new tree with changes.  What is the easiest way to merge his changes.  My tree has diverged a little with other changes, but I think I can revert back to a common ancestor.17:13
vilawell, stacking repos was originally designed to handle access rights, where the feature branches are not allowed to add their revisions to the trunk repo (used by the trunk branch)17:14
vilaGrueMaster: url for the mp ?17:14
farbluevila: yeah, I read that and wondered whether that could apply to a readonly upstream project17:14
vilafarblue: have a look at what a 'parallel import' can cause :-/17:16
GrueMasterI also have a local copy of his branch.  I do most of my work in Linux.17:16
vilaGrueMaster: simpler answer: ask the submitter to start from your branch17:16
GrueMasterI've suggested that a few times now.  Apparently Windows devs don't work well with cmdline tools.  :P17:17
vilaGrueMaster: oh, we have a GUI for them :)17:17
GrueMasterI know, I have it on my VM of XP.17:18
vilaGrueMaster: it's even available in the all-in-one installer for windows at .. ok17:18
vilaso, more involved answer: pain17:18
GrueMasterDoesn't help the current situation.17:18
farbluein the situation where upstream do have a vcs in, say, subversion, what would be the recommended approach? Can you create a 'vendor branch' based on the svn release branch and then 'switch' to the new release and merge the changes?17:18
vilafarblue: use bzr-svn17:19
mgzGrueMaster: make a new local branch at the revision he got the tarball from,17:19
vilaGrueMaster: ok, so the semi-easy answer is to get the proposed branch, copy the files (excluding .bzr) to a copy of your trunk17:19
mgzget the diff from launchpad and apply it17:19
GrueMasterAnd manual diff?  ugh17:20
farblueso you use bzr-svn to create a 'pull' from, say, release branch 1.0 of the upstream project - what  is the process when they release  version 1.1 on a new release branch or tag?17:20
mgzdo `bzr commit --author {that guy}` ...17:20
vilafarblue: 'bzr pull'17:20
GrueMasterThat part I know.  I do that whenever someone just sends a patch.17:20
vilafarblue: or 'bzr pull -rtag:<tag>'17:20
mgzthen merge17:21
farblueok, so that pulls the latest from upstream.  then what? merge as normal?17:21
mgzGrueMaster: you should just be able to get his branch, and copy over the changes if you don't want fiddle with patches17:21
mgzthe trick is knowing what his rev 1 corresponds to in your real branch17:21
GrueMasterSince he made changes first before adding them to a new tree, the entire project looks like a diff.17:22
farbluevila: thanks :D very interesting that it works for cross-vcs17:22
vilathe tricky part is to make sure you use the correct file-ids or you'll fall into the same kind of issues GrueMaster is facing17:22
mgzsure, but if you ignore the fact he created a branch at all17:22
GrueMasterCommit 1 baseline is therefore already a diff.17:22
mgzand just copy across the tree17:22
vilafarblue: yeah, many thanks to jelmer for that ;)17:22
farbluequite! and the same for git and hg?17:23
mgzpresumably he started from some tag or other you released17:23
vilafarblue: yup, bzr-hg is still beta, but bzr-svn and bzr-git are used in production17:24
farbluecool :)17:24
farbluethanks for all your help :)17:24
GrueMasterSo, you are saying make a separate branch from my tree with the starting point before his change, then just copy his files over the top?  I'll give that a try.17:24
vilaLarstiQ: because I didn't forget, config numbers: https://pastebin.canonical.com/60280/17:25
vilaLarstiQ: based on the config hooks triggered for the corresponding actions (load -> read file, save -> write file, the other should self-explanatory)17:26
vilaLarstiQ: the numbers don't match as the changes were introduced along the way (as well as new options), but the overall picture is still relevant17:27
vilaLarstiQ: oh, and that's from running: BZR_PLUGIN_PATH=-site ./bzr selftest --parallel=fork -Econfig_stats --subunit on all revisions and then using ./tools/subunit-sum17:28
* vila face palms, wrong paste site17:29
vilaLarstiQ: instructions to reproduce: http://paste.ubuntu.com/843297/ but be aware I've been catching up when you ask this morning and only had to process ~80 revs (and it just finished ;-p)17:31
LarstiQvila: so a 700k drop in old_config.load for a 50k gain in new_config.load, not bad!17:43
vilayup, and that's without caching 'bazaar.conf' and 'locations.conf'17:43
LarstiQvila: an increase of 250k gets though seems quite high?17:45
vilaLarstiQ: if there are new gets, it means we're using more options ;)17:46
vilathe point is to make get cheap, not to reduce its usage17:46
LarstiQvila: fair enough :)17:49
LarstiQvila: is it easy to find out where they come from?17:49
vilabut 250k more for 20.000 tests still is weird, there is probably something worth investigating17:50
vilaprobably by making the hooks collect the option/file names17:50
=== deryck is now known as deryck[lunch]
=== iBasic is now known as BasicOSX
=== deryck[lunch] is now known as deryck
friedrichI am trying to learn about bazaar, but I don't understand shared repos yet: How do i reconstruct if I deleted all folders and files within a shared repo, except the ".bzr" in the top-level ?21:52
bob2you can't21:53
friedrichbut the .bzr in the top-level holds all information (guessing from the file size)21:54
bob2it holds much of the information21:55
bob2but the dirs you deleted hold the branch pointers21:55
friedrichhm, ok21:55
fullermdYou may be able to reconstruct much of it by poking around in 'heads'.21:57
fullermdIf you don't have a lot of dead heads in your repo (deleted branches, uncommits, etc), it could be fairly easy.21:58
fullermdYou've lost any branch config (remembered locations, frex), but you should be able to find the revs at least.21:58
bob2helpfully will even have branch names in bzr21:58
friedrichdon't worry, it was just some test data, while trying to understand bzr21:59
bob2friedrich, so .bzr in the repo root holds all the rev data, the 'branch directories' mostly just tell bzr which rev in the repo is the head of that branch21:59
friedrichcoming from monotone or fossil-scm I thought that there would be some easy way to reconstruct21:59
bob2deleting those dirs is explicitly throwing data away22:00
fullermdThe shared repo is basically a big bucket full of revisions.  No real order or structure.22:02
abentleyjelmer: I would like automatic nicknames to use the Branch.name for colocated branches.  Does that make sense to you?22:02
fullermdThe branch dir is what says "these revs are mine", plus some ancillary bits like the saved push/pull/etc locations, possibly a nickname, and more rarely various other stuff.22:02
fullermdThere's a 'heads' command in bzrtools that will dig through the repo and tell you what 'head' revisions are in there, which are likely to have been the heads of branches.  With that you can make a new branch with that head.22:03
fullermdSo the history of the branch can be recovered (well, it's already there; made accessible anyway).22:03
fullermdIf you've got a lot of dead heads (like you'd get from uncommit, or abandoning and deleting a branch), it might take some work to dig out the ones you care about from the noise.22:04
fullermdAnd if you had branches whose revs aren't heads (had descendents), you'd have to pretty much know what they are to get them back.22:04
friedrichok, I will check out bzrtools - thanks22:05
abentleyfriedrich: If you do have a lot of dead heads, --by-date will show what's most recent.22:06
pooliehi all22:26
abentleypoolie: hi.22:28
pooliehi there22:29
pooliethanks for nc:22:29
abentleypoolie: no problem.  It was so trivial I nearly didn't announce it.22:30
pooliei was going to say maybe you should just merge it22:30
pooliebut, perhaps defaulting to the bzrdir of . is a bit too weird to support22:30
abentleypoolie: So I guess if you have a lightweight checkout of a colocated branch, nc: should refer to the bzrdir of the referenced branch.22:32
abentleypoolie: using the current bzrdir reflects a (not entirely crazy) assumption that your lightweight checkout is colocated with the colocated branches.22:33
poolieanyhow if you wanted to merge it, perhaps with a note in the help that it's experimental, that would be ok with me22:33
pooliemaybe make it x-nc:22:33
abentleypoolie: I thought the plan was to get other commands respecting colocated branches shortly, so that nc would not be useful for long.  But if you want it in core, I can do that.22:34
pooliei think, generally, if there's a small and not harmful interim improvement, it's better to merge it than to count on the real fix arriving soon22:37
abentleypoolie: Do we have a user-facing term for Branch.name?22:41
pooliei'm not sure22:41
poolienot 'branch name'?22:41
abentleypoolie: I dunno, I just thought it might not be specific enough-- could refer to the basename of the branch or is nickname.  But I've come up with some verbiage I like.  I'll post the merge proposal in a minute.22:45
pooliewell, we should be consistent about it, and put it in a comment next to branch.name, and in overview.txt22:46
pooliei agree that may be a bit generic22:46
abentleypoolie: Does vila's new stuff give us a way of substituting the branch nick or branch name in config files the way we used to do with appendpath?22:49
poolieit may require some amount of glue to make it available there22:49
poolie*small amount, hopefully22:49
abentleypoolie: I can't find any documentation.  Has it landed yet?22:55
poolieso it is landed, in Config.expand_options, etc23:00
poolieit doesn't look very documented though23:01
pooliei'll mail him23:04
poolieabentley, i think the short story is that you need to define a config variable for the thing you want to insert, with a default method that calculates the right value23:05
pooliethen you can just expand that with {foo} inside other values23:05
abentleypoolie: The default method is provided in Bazaar?23:06
poolieyou declare and register an Option object, and its default= constructor parameter is a callable23:07
poolieit seems like it ought to be called with some context23:07
* abentley is kinda surprised that nickname isn't already registered.23:12
lifelesspoolie: hi23:13
pooliehi there23:13
poolieshould have pung23:13
pooliehow about now?23:13
lifelessme being online and all :P23:14
abentleypoolie: This is what I was doing: https://code.launchpad.net/~abentley/bzr/name-nick/+merge/9331923:27

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!