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