| poolie | hi all | 00:50 |
|---|---|---|
| wgz | ack, I need to be in bed if I'm gonna make tomorrow morning | 00:51 |
| poolie | sleep well :) | 00:51 |
| wgz | night! | 00:52 |
| === maxb_ is now known as maxb | ||
| === RickCogley_ is now known as RickCogley | ||
| poolie | lifeless, did you see http://giovanni.bajo.it/2011/09/golomb-coded-sets/ | 05:51 |
| lifeless | poolie: interesting! | 06:15 |
| poolie | it's a very elegant series of steps | 06:22 |
| lifeless | indeed | 06:27 |
| poolie | i'd like to have a chat with you some time this week | 06:28 |
| AuroraBorealis | https://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 |
| ubot5 | Ubuntu bug 847388 in Bazaar ""gpg: cannot open `/dev/tty': No such device or address" on Ubuntu when signing commits" [Medium,In progress] | 06:29 |
| poolie | AuroraBorealis, solved how? | 06:30 |
| poolie | we pass the option, or we give it a tty, or gpg stopped complaining? | 06:30 |
| AuroraBorealis | my 'change' in that branch is literally just adding --no-tty to the gpg arguments | 06:30 |
| lifeless | poolie: 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 free | 06:30 |
| poolie | oh you're mark? | 06:31 |
| AuroraBorealis | that makes it so it WORKs on ubuntu (which was the only OS that had problems), and it still works as intended on mac/windows | 06:31 |
| AuroraBorealis | yeah. i should probably use that name here xD | 06:31 |
| poolie | if you want to only land it on trunk i think you can just put it in | 06:31 |
| poolie | if it's intended for 2.5 we have to be quite careful | 06:31 |
| AuroraBorealis | i dunno how to 'put it in' or if its indended for 2.5 | 06:32 |
| AuroraBorealis | it pretty much makes bazaar explorer unusable if you are signing commits (since you can't commit with it) | 06:33 |
| poolie | so you're prettysure that has no (harmful) effect on windows? | 06:36 |
| poolie | i don't expect it would | 06:36 |
| AuroraBorealis | i tried it | 06:36 |
| poolie | oh, great | 06:36 |
| AuroraBorealis | i just downloaded my branch and ran the bzr python file, tried creating a repo and commiting with the signing | 06:37 |
| poolie | ok so you should just click 'propose for merging' on https://code.launchpad.net/~markgrandi/bzr/gpg_devttynotfound_fix | 06:37 |
| poolie | and choose lp:bzr/2.5 as the target | 06:38 |
| AuroraBorealis | i 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 =P | 06:38 |
| AuroraBorealis | ~bzr-pqm/bzr/2.5 that it? | 06:39 |
| poolie | that's it | 06:39 |
| poolie | yes, http://doc.bazaar.canonical.com/beta/en/user-reference/verify-signatures-help.html | 06:39 |
| AuroraBorealis | hmm needs some weird package installed on windows | 06:40 |
| AuroraBorealis | i'll try it later | 06:41 |
| poolie | ok | 06:41 |
| poolie | i would be reluctant to put it in after the last beta unless it was well tested across platforms | 06:41 |
| poolie | really only windows is a concern though | 06:41 |
| poolie | mm | 06:41 |
| poolie | lifeless, ok, 12nz tomorrow? | 06:44 |
| lifeless | sure | 06:44 |
| mgz | morning all! | 07:39 |
| vila | morning mgz et al. | 07:41 |
| poolie | hi mgz, hi vila | 07:42 |
| poolie | mgz i replied on https://bugs.launchpad.net/bzr/+bug/851834 | 07:42 |
| ubot5 | Ubuntu 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 |
| mgz | poolie: thanks | 07:43 |
| poolie | i'm not sure it will help but that's what i'd try next | 07:55 |
| wgz | is the kind of thing I was after | 07:57 |
| poolie | wgz, then you can open the pcap file in wireshark | 08:02 |
| poolie | with which jelmer is an expert | 08:02 |
| wgz | the use of jelmer is also something I'm in favour of | 08:03 |
| jelmer | *ahem* :) | 08:06 |
| vila | jelmer: so, re-reading http://docs.python.org/library/ssl.html?highlight=cert_optional#ssl.CERT_OPTIONAL | 09:17 |
| vila | jelmer: certificates will be required from the other side, i.e. required from the server by the client | 09:17 |
| vila | jelmer: that's about the server certificate not about the client root certificates | 09:17 |
| jelmer | vila: ah, ok | 09:18 |
| jelmer | vila: so I guess we'll need a new option after all | 09:18 |
| vila | well, a new value for the option will do in the interim | 09:19 |
| vila | what I want to avoid is people setting it in their config file and don't use the default when we change it | 09:19 |
| vila | s/I want/I'd like/ ;) | 09:19 |
| mgz | something as dumb as ssl.cert_reqs default being 'none' on win and osx and 'required' otherwise would be okay for now | 09:34 |
| farblue | morning 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 trunk | 09:56 |
| Peng | What's --record-only? | 09:58 |
| farblue | it is used during a merge to mark the merge as having been done but without actually applying the patch | 09:58 |
| farblue | for 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 |
| farblue | we want to merge the release branch back to trunk to prevent regressions but we don't want that particular commit to be merged back | 09:59 |
| Peng | You 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 |
| poolie | thanks Peng | 10:00 |
| poolie | night all | 10:00 |
| farblue | ok, that's a reasonable option | 10:01 |
| farblue | a little less intuitive than the --record-only svn option but at least there is a way :) | 10:01 |
| farblue | any other ideas? any plugins that might help? | 10:02 |
| farblue | Just gathering support for bzr over other options you see :) Need to put forward a good case :) | 10:02 |
| poolie | farblue, that's how it's done at the moment | 10:09 |
| poolie | mm | 10:09 |
| vila | mgz: works for me, will file a mp doing that | 10:09 |
| poolie | you could fairly easily patch bzr to add a --record-only if you want | 10:09 |
| farblue | good point :) | 10:09 |
| farblue | I 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 patch | 10:10 |
| farblue | anyhow, thanks :D | 10:11 |
| === yofel_ is now known as yofel | ||
| LarstiQ | vila: do you have any numbers for how much an improvement the config caching is? | 10:39 |
| vila | LarstiQ: 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 landed | 10:40 |
| vila | ghaa, unity 2D has some rough edges :-/ | 10:40 |
| mgz | sharp edges, being a planar surface I'd expect. | 10:41 |
| vila | hehe | 10:42 |
| LarstiQ | vila: ah right. About 1 to 2 less hpss calls in 10 places | 10:42 |
| vila | LarstiQ: 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 file | 10:43 |
| LarstiQ | mgz: ah hmm, but the regularity of the edge might be pretty bad | 10:44 |
| LarstiQ | vila: and within a lock it will only read once? | 10:44 |
| vila | LarstiQ: 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 it | 10:45 |
| vila | LarstiQ: almost yes | 10:45 |
| vila | LarstiQ: that is, without modifications, it's read only once | 10:45 |
| vila | LarstiQ: if there is at least one modification, it needs to be read again (to protect potential modifications made by other processes) and write once | 10:46 |
| LarstiQ | vila: right. So then we'd expect more benefit on longer lived operations | 10:46 |
| * LarstiQ nods | 10:46 | |
| vila | LarstiQ: 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 |
| LarstiQ | aye | 10:47 |
| vila | hmm, 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 in | 10:49 |
| vila | it's worse if the windows you're interested in is already visible of course... | 10:49 |
| vila | mgz, jelmer: https://code.launchpad.net/~vila/bzr/929179-default-ssl-certs/+merge/93177 is up for review | 10:50 |
| vila | mgz: may be you should include that for the 2.5b6 windows installers and get them out of the door :) | 10:50 |
| vila | mgz: also see bug #932647 for more info I gathered on the windows native calls | 10:51 |
| ubot5 | Launchpad bug 932647 in Bazaar "native root certificates should be supported on windows" [High,Confirmed] https://launchpad.net/bugs/932647 | 10:51 |
| farblue | hi again :) | 11:07 |
| farblue | a quick question about revision numbers - I understand the incrementing number and the . separated numbers for branches | 11:08 |
| farblue | but are these global for the repo or are they specific to my copy of the repo? | 11:08 |
| farblue | e.g. if i refer to revision 1234 will it be the same revision as rev 1234 on a colleague's machine? | 11:09 |
| quicksilver | if they're looking at the same branch | 11:10 |
| quicksilver | then they'll have the same numbers. | 11:10 |
| farblue | I'm assuming 'trunk' here as there are no dots in the number | 11:10 |
| quicksilver | if you like revision numbers (we do!) then you will want to make sure you don't "push" onto one of your main trees | 11:10 |
| quicksilver | ...from a different branch | 11:10 |
| quicksilver | pushing from a different branch can pivot the revision numbers. | 11:11 |
| quicksilver | instead, merge + commit into the branch and keep your revnos monotonic. | 11:11 |
| farblue | so you mean we should merge our work onto the 'trunk' and then push trunk? | 11:11 |
| quicksilver | if you are working on separate branches, yes. | 11:11 |
| quicksilver | if you are just working directly on trunk it doesn't matter. | 11:11 |
| farblue | ok | 11:12 |
| quicksilver | if you *are* working directly on trunk then I recommend a 'bound branch' | 11:12 |
| quicksilver | that 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 trunk | 11:13 |
| quicksilver | is the workflow we use. | 11:13 |
| LarstiQ | farblue: you can also set the `append_only` option on trunk | 11:13 |
| farblue | Currently 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 work | 11:13 |
| farblue | append_only means it won't re-shuffle the revisions, I gather | 11:14 |
| * LarstiQ nods | 11:14 | |
| quicksilver | yes 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 |
| quicksilver | LarstiQ: thanks, I didn't know about that one. | 11:15 |
| farblue | cool :) | 11:15 |
| LarstiQ | `append_revisions_only` is the correct name according to `bzr help configuration` | 11:15 |
| === zyga is now known as zyga-afk | ||
| farblue | We 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 |
| quicksilver | agree farblue | 11:18 |
| quicksilver | so do we | 11:18 |
| quicksilver | also redmine^Wchiliproject's repo viewer gets confused if revision numbers change. | 11:18 |
| quicksilver | LarstiQ: will it also forbid the occasionally bzr push --overwrite where we really *do* need to change history? | 11:19 |
| LarstiQ | quicksilver: yes | 11:20 |
| mgz | yes, but you can flip the config, push, and flip it back | 11:20 |
| quicksilver | nod | 11:20 |
| quicksilver | thanks | 11:20 |
| jelmer | vila: did your RangeFile.read patch land? | 12:08 |
| vila | I think so | 12:09 |
| vila | jelmer: found another case where it's not enough ? | 12:09 |
| jelmer | vila: yeah | 12:10 |
| vila | :-/ | 12:11 |
| jelmer | I guess you've only fixed it for the size=-1 case? | 12:11 |
| vila | details ? | 12:11 |
| vila | well, I was testing with an import that used size=16384 or something, may be I didn't run it against the last version | 12:11 |
| jelmer | I'm calling read(1024) on a RangeFile returned by HttpTransport_urllib.get() | 12:12 |
| vila | and ? | 12:12 |
| vila | I mean, how does it fail ? | 12:12 |
| jelmer | bzr: 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 blinks | 12:12 | |
| vila | the error is supposed to be raised by a different code path | 12:13 |
| vila | so 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 |
| jelmer | ah, yeah | 12:14 |
| jelmer | vila: sorry, pebkac | 12:14 |
| jelmer | I'm indeed using an older bzr version | 12:14 |
| vila | no worries, better safe than sorry | 12:15 |
| * vila re-runs his test for good measure, blaming unity 2D for making it harder to work with multiple workspaces ;) | 12:16 | |
| farblue | Can 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 |
| farblue | bzr* (autocorrect fail) | 12:23 |
| farblue | to help prevent 2 people working on a binary asset at the same time | 12:24 |
| wgz | https://lists.ubuntu.com/archives/bazaar/2008q4/050125.html | 12:29 |
| wgz | https://lists.ubuntu.com/archives/bazaar/2010q1/067494.html | 12:29 |
| farblue | interesting | 12:32 |
| farblue | does it work? anyone using it? | 12:33 |
| Riddell | congratulations jelmer | 12:53 |
| === zyga-afk is now known as zyga | ||
| jelmer | Riddell: thanks, what for ? :) | 12:56 |
| Riddell | jelmer: the canonical spotlight award! | 12:57 |
| mgz | hey, there's a prize and everything. go jelmer. | 13:00 |
| jml | +1 | 13:01 |
| jelmer | wow, thanks! :) I hadn't seen the email yet | 13:01 |
| GRiD | congrats jelmer | 13:30 |
| vila | cong... 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 | |
| vila | quicksilver:hehe, sry, he got some company internal award for being our... dude ;) | 15:21 |
| quicksilver | jelmer++ # dude | 15:22 |
| jelmer | heh, thanks vila, quicksilver :) | 15:23 |
| mgz | I think we ought to make congratulate jelmer day a regular thing | 15:50 |
| mgz | makes a nice change from why haven't fixed my pet bug yet jelmer days | 15:50 |
| vila | mgz: +1 | 15:51 |
| vila | jelmer: 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 it | 16:30 |
| jelmer | vila: merci bien ! | 16:36 |
| farblue | hi all :) | 16:45 |
| farblue | does anyone have experience of dealing with 'vendor branches' in bzr? | 16:47 |
| vila | farblue: we are GPL hackers, we don't sell anything, all branches are free ;) | 16:48 |
| farblue | lol | 16:48 |
| vila | farblue: joke aside, all branches are equal except when social conventions apply | 16:49 |
| vila | so a 'vendor branch' is just a branch and how you interact with it depends on your workflow | 16:49 |
| farblue | ok, let me rephrase: dealing with developing on top of a third-party source code for which you only see the release versions | 16:49 |
| vila | you can maintain a vendor branch with its own set of changes and still merge regularly from trunk | 16:50 |
| vila | oh, you mean the release versions are not under version control at all and you get only tarballs ? | 16:50 |
| farblue | yep | 16:51 |
| farblue | currently we spend ages in svn applying the new source over the top of our 'vendor branch' | 16:51 |
| farblue | and it's a pain | 16:51 |
| farblue | of course, once done we can merge the changes into trunk and all is rather easier | 16:51 |
| farblue | but that initial application of the new source dump over the top of our 'vendor branch' is a real pain | 16:52 |
| vila | yup, the crucial point is to track the releases in a bzr branch that share history with *your* stuff | 16:52 |
| farblue | anyone got experience of how well bzr handles this? | 16:52 |
| farblue | yeah, 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 horrible | 16:53 |
| farblue | just wondering whether life would be easier when using bzr | 16:53 |
| vila | pretty well as long as you can avoid your 'parallel import' nemesis | 16:53 |
| farblue | parallel import? | 16:53 |
| vila | bzr tracks renames by assigning a file-id when a file is first added | 16:54 |
| vila | there is a catch: if the same file is added independently, it gets a different file-id (it is imported in parallel) | 16:55 |
| farblue | right | 16:55 |
| farblue | so, 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 |
| vila | if you already have a branch with your stuff, create a new branch from that, untar the upstream source, commit | 16:56 |
| farblue | won't that then mark the incoming changes from upstream as 'newer' than our changes? | 16:57 |
| vila | well, ideally you start from the upstream source and create a branch for your stuff avoiding the issue, the trick above is for catching up | 16:57 |
| vila | 'newer' depends on when you merge this upstream branch into your trunk | 16:58 |
| vila | if you maintain the upstream branch separately and always untar there, things will become clearer in the long term | 16:58 |
| vila | farblue: 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, etc | 16:59 |
| farblue | in 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 |
| farblue | does this basically sound the same as how you'd do it in bzr? | 17:00 |
| vila | yup | 17:00 |
| farblue | fine, ok :) For us it is step one - "updating the vendor branch to the latest version" that is the painful bit :( | 17:01 |
| vila | the caveat is about *starting* the upstream branch | 17:01 |
| vila | really ? | 17:01 |
| farblue | well, 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 releases | 17:02 |
| vila | ha | 17:02 |
| farblue | a real pain actually | 17:02 |
| vila | well, it's hard to get VCS benefits if upstream doesn't use VCS... | 17:03 |
| farblue | hmm | 17:03 |
| vila | are you sure you can't access their VCS repo ? | 17:03 |
| farblue | well, for Roundcube we are considering it but they've also got better at releasing more frequently | 17:03 |
| farblue | for other projects there is no public vas available | 17:04 |
| vila | java code ? | 17:04 |
| farblue | php | 17:04 |
| vila | the only tricky part should be renames, unless you're talking about changes to code that is moved from one file to another | 17:05 |
| vila | file/dir renames I mean | 17:05 |
| farblue | well the worst situation for svn is where a file we have modified is renamed / moved in the upstream project | 17:06 |
| LarstiQ | farblue: unpack into vendor branch, and then some combination of bzr add/bzr mv --auto/after? | 17:06 |
| farblue | what's the --auto/after stuff? | 17:07 |
| vila | guess the renames :) | 17:07 |
| LarstiQ | farblue: I'd need to try out the workflow, but I think `unpack; bzr mv --auto; bzr add` | 17:07 |
| farblue | guess the renames? cool :) Even if there has been a percentage of the source changed within the renamed file? | 17:08 |
| vila | farblue: or more precisely: guess the renames based on the content | 17:08 |
| LarstiQ | farblue: `bzr help mv` doesn't elaborate too much, but --auto tries to guess renames | 17:08 |
| vila | farblue: yup | 17:08 |
| farblue | very useful :) | 17:08 |
| vila | that could fail if the changes are too broad of course | 17:08 |
| farblue | in many cases it's just a case of a folder having been renamed or similar but svn still hates this | 17:09 |
| vila | but you can focus on those after most of the trivial ones have been handled | 17:09 |
| farblue | yes, the ability to attempt to guess at renames is very useful | 17:09 |
| vila | I'm not sure --auto handle dir renames but bzr will track them happily | 17:09 |
| farblue | sounding good :) | 17:10 |
| vila | basically, if you don't have the VCS history, you have to provide the minimal missing bits | 17:11 |
| farblue | yeah | 17:11 |
| farblue | now 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 |
| vila | stacking is for repos more than for branches, avoid ti if you can ;) | 17:12 |
| farblue | ok | 17:13 |
| vila | s/ti/it/ | 17:13 |
| farblue | sounds like the advice I give to people enquiring about svn:externals :) | 17:13 |
| GrueMaster | Hey. 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 |
| vila | well, 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 |
| vila | GrueMaster: url for the mp ? | 17:14 |
| farblue | vila: yeah, I read that and wondered whether that could apply to a readonly upstream project | 17:14 |
| GrueMaster | https://code.launchpad.net/~skydiver38/win32-image-writer/md5/+merge/88565 | 17:15 |
| vila | farblue: have a look at what a 'parallel import' can cause :-/ | 17:16 |
| GrueMaster | I also have a local copy of his branch. I do most of my work in Linux. | 17:16 |
| vila | GrueMaster: simpler answer: ask the submitter to start from your branch | 17:16 |
| GrueMaster | I've suggested that a few times now. Apparently Windows devs don't work well with cmdline tools. :P | 17:17 |
| vila | GrueMaster: oh, we have a GUI for them :) | 17:17 |
| GrueMaster | I know, I have it on my VM of XP. | 17:18 |
| vila | GrueMaster: it's even available in the all-in-one installer for windows at .. ok | 17:18 |
| vila | so, more involved answer: pain | 17:18 |
| GrueMaster | Doesn't help the current situation. | 17:18 |
| farblue | in 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 |
| vila | farblue: use bzr-svn | 17:19 |
| mgz | GrueMaster: make a new local branch at the revision he got the tarball from, | 17:19 |
| vila | GrueMaster: ok, so the semi-easy answer is to get the proposed branch, copy the files (excluding .bzr) to a copy of your trunk | 17:19 |
| mgz | get the diff from launchpad and apply it | 17:19 |
| GrueMaster | And manual diff? ugh | 17:20 |
| farblue | so 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 |
| GrueMaster | grmbl. | 17:20 |
| mgz | do `bzr commit --author {that guy}` ... | 17:20 |
| vila | farblue: 'bzr pull' | 17:20 |
| GrueMaster | That part I know. I do that whenever someone just sends a patch. | 17:20 |
| vila | farblue: or 'bzr pull -rtag:<tag>' | 17:20 |
| mgz | then merge | 17:21 |
| farblue | ok, so that pulls the latest from upstream. then what? merge as normal? | 17:21 |
| vila | yup | 17:21 |
| mgz | GrueMaster: you should just be able to get his branch, and copy over the changes if you don't want fiddle with patches | 17:21 |
| mgz | the trick is knowing what his rev 1 corresponds to in your real branch | 17:21 |
| GrueMaster | Since he made changes first before adding them to a new tree, the entire project looks like a diff. | 17:22 |
| farblue | vila: thanks :D very interesting that it works for cross-vcs | 17:22 |
| vila | the tricky part is to make sure you use the correct file-ids or you'll fall into the same kind of issues GrueMaster is facing | 17:22 |
| mgz | sure, but if you ignore the fact he created a branch at all | 17:22 |
| GrueMaster | Commit 1 baseline is therefore already a diff. | 17:22 |
| mgz | and just copy across the tree | 17:22 |
| vila | farblue: yeah, many thanks to jelmer for that ;) | 17:22 |
| farblue | quite! and the same for git and hg? | 17:23 |
| mgz | presumably he started from some tag or other you released | 17:23 |
| vila | farblue: yup, bzr-hg is still beta, but bzr-svn and bzr-git are used in production | 17:24 |
| farblue | cool :) | 17:24 |
| farblue | thanks for all your help :) | 17:24 |
| GrueMaster | So, 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 |
| mgz | yup. | 17:24 |
| vila | LarstiQ: because I didn't forget, config numbers: https://pastebin.canonical.com/60280/ | 17:25 |
| vila | LarstiQ: based on the config hooks triggered for the corresponding actions (load -> read file, save -> write file, the other should self-explanatory) | 17:26 |
| vila | LarstiQ: the numbers don't match as the changes were introduced along the way (as well as new options), but the overall picture is still relevant | 17:27 |
| vila | LarstiQ: 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-sum | 17:28 |
| * vila face palms, wrong paste site | 17:29 | |
| vila | http://paste.ubuntu.com/843296/ | 17:29 |
| vila | LarstiQ: 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 |
| LarstiQ | vila: so a 700k drop in old_config.load for a 50k gain in new_config.load, not bad! | 17:43 |
| vila | yup, and that's without caching 'bazaar.conf' and 'locations.conf' | 17:43 |
| LarstiQ | vila: an increase of 250k gets though seems quite high? | 17:45 |
| vila | LarstiQ: if there are new gets, it means we're using more options ;) | 17:46 |
| vila | the point is to make get cheap, not to reduce its usage | 17:46 |
| LarstiQ | vila: fair enough :) | 17:49 |
| LarstiQ | vila: is it easy to find out where they come from? | 17:49 |
| vila | but 250k more for 20.000 tests still is weird, there is probably something worth investigating | 17:50 |
| vila | probably by making the hooks collect the option/file names | 17:50 |
| === deryck is now known as deryck[lunch] | ||
| === iBasic is now known as BasicOSX | ||
| === deryck[lunch] is now known as deryck | ||
| friedrich | hello | 21:51 |
| friedrich | I 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 |
| bob2 | you can't | 21:53 |
| friedrich | but the .bzr in the top-level holds all information (guessing from the file size) | 21:54 |
| bob2 | it holds much of the information | 21:55 |
| bob2 | but the dirs you deleted hold the branch pointers | 21:55 |
| bob2 | afair | 21:55 |
| friedrich | hm, ok | 21:55 |
| fullermd | You may be able to reconstruct much of it by poking around in 'heads'. | 21:57 |
| fullermd | If you don't have a lot of dead heads in your repo (deleted branches, uncommits, etc), it could be fairly easy. | 21:58 |
| bob2 | true | 21:58 |
| fullermd | You've lost any branch config (remembered locations, frex), but you should be able to find the revs at least. | 21:58 |
| bob2 | helpfully will even have branch names in bzr | 21:58 |
| friedrich | don't worry, it was just some test data, while trying to understand bzr | 21:59 |
| bob2 | friedrich, 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 branch | 21:59 |
| friedrich | coming from monotone or fossil-scm I thought that there would be some easy way to reconstruct | 21:59 |
| bob2 | deleting those dirs is explicitly throwing data away | 22:00 |
| fullermd | The shared repo is basically a big bucket full of revisions. No real order or structure. | 22:02 |
| abentley | jelmer: I would like automatic nicknames to use the Branch.name for colocated branches. Does that make sense to you? | 22:02 |
| fullermd | The 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 |
| fullermd | There'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 |
| fullermd | So the history of the branch can be recovered (well, it's already there; made accessible anyway). | 22:03 |
| fullermd | If 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 |
| fullermd | And 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 |
| friedrich | ok, I will check out bzrtools - thanks | 22:05 |
| abentley | friedrich: If you do have a lot of dead heads, --by-date will show what's most recent. | 22:06 |
| poolie | hi all | 22:26 |
| abentley | poolie: hi. | 22:28 |
| poolie | hi there | 22:29 |
| poolie | thanks for nc: | 22:29 |
| abentley | poolie: no problem. It was so trivial I nearly didn't announce it. | 22:30 |
| poolie | i was going to say maybe you should just merge it | 22:30 |
| poolie | but, perhaps defaulting to the bzrdir of . is a bit too weird to support | 22:30 |
| abentley | poolie: 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 |
| abentley | poolie: using the current bzrdir reflects a (not entirely crazy) assumption that your lightweight checkout is colocated with the colocated branches. | 22:33 |
| poolie | right | 22:33 |
| poolie | anyhow if you wanted to merge it, perhaps with a note in the help that it's experimental, that would be ok with me | 22:33 |
| poolie | maybe make it x-nc: | 22:33 |
| abentley | poolie: 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 |
| poolie | i 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 soon | 22:37 |
| abentley | poolie: Do we have a user-facing term for Branch.name? | 22:41 |
| poolie | i'm not sure | 22:41 |
| poolie | not 'branch name'? | 22:41 |
| abentley | poolie: 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 |
| poolie | mm | 22:46 |
| poolie | well, we should be consistent about it, and put it in a comment next to branch.name, and in overview.txt | 22:46 |
| poolie | i agree that may be a bit generic | 22:46 |
| abentley | poolie: 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 |
| poolie | yes | 22:49 |
| poolie | it may require some amount of glue to make it available there | 22:49 |
| poolie | *small amount, hopefully | 22:49 |
| abentley | poolie: I can't find any documentation. Has it landed yet? | 22:55 |
| poolie | looking | 22:58 |
| poolie | so it is landed, in Config.expand_options, etc | 23:00 |
| poolie | it doesn't look very documented though | 23:01 |
| poolie | i'll mail him | 23:04 |
| poolie | abentley, 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 value | 23:05 |
| poolie | then you can just expand that with {foo} inside other values | 23:05 |
| abentley | poolie: The default method is provided in Bazaar? | 23:06 |
| poolie | you declare and register an Option object, and its default= constructor parameter is a callable | 23:07 |
| poolie | hm | 23:07 |
| poolie | it seems like it ought to be called with some context | 23:07 |
| * abentley is kinda surprised that nickname isn't already registered. | 23:12 | |
| lifeless | poolie: hi | 23:13 |
| poolie | hi there | 23:13 |
| poolie | should have pung | 23:13 |
| poolie | how about now? | 23:13 |
| lifeless | sure | 23:14 |
| lifeless | me being online and all :P | 23:14 |
| abentley | poolie: This is what I was doing: https://code.launchpad.net/~abentley/bzr/name-nick/+merge/93319 | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!