[01:27] <maxb> I've produced a fast-import file with cvs2bzr, and "bzr fast-import"ed it, and some branches appear to be missing!
[01:27] <maxb> Is there anything obvious I should look at?
[01:31] <spiv> igc: ^
[01:33] <igc> maxb: bzr fast-import only generates branches for 'heads' in the final revision graph. Maybe some branches are now similar tags on trunk?
[01:33] <igc> simply
[01:33] <maxb> hmm
[01:34] <maxb> It's a cvs2bzr conversion, so in theory branches should only branch, never merge
[01:34] <maxb> It's possibly there might be a trunk revision which is tree-wise identical in this case, though?
[01:35] <maxb> Is there any way I can dump all the revisions in a *repository*, to grep for the commit messages on the missing branch?
[01:36] <igc> maxb: maybe some branches were made from trunk and never received any changes after creation?
[01:36] <maxb> I can see a commit on the branch in the fast-import stream
[01:36] <igc> maxb: qlog lets you browse a repo and search within it
[01:37] <maxb> an entire repo? I thought it took branches
[01:37] <igc> log will only take a branch; qlog is smarter than that
[01:45] <maxb> I apologize, it appears my missing branch got merged by a tag in an unexpected way
[01:49] <igc> maxb: maybe we need to improve the feedback fast-import gives?
[01:49] <igc> maxb: could you raise a bug if there's a problem or we could do better?
[01:49] <maxb> would be nice - it's a little scary when a branch name you know should exist, doesn't
[01:50] <igc> maxb: I'll be online now for a hour or two so a bug report is the best way to get things improved
[01:51] <igc> max: if nothing else, maybe we need an FAQ or better doc
[01:51]  * igc bbl - out for a bit
[01:51] <maxb> Perhaps it should say something like "Branch A is wholly merged into branch B - not writing an active branch"
[04:22] <igc> back
[05:59] <poolie1> igc, hi, does bug 430179 still need fixing in bzr itself?
[06:00] <igc> I don't believe so. The installer is a separate project now
[06:00] <igc> poolie1: ^^^
[06:01] <poolie1> thanks
[06:01] <igc> poolie1: bbiab - need to pick up kids from school
[06:06] <poolie1> spiv, how are you today?
[06:09] <spiv_> poolie1: good, fixing https://bugs.edge.launchpad.net/bzr/+bug/389413
[06:13] <spiv> poolie1: I'm thinking it might be nice to have a debug flag that mutters whenever a tree, branch or repository object acquires a lock, releases a lock, and acquires it again.
[06:13] <poolie1> to tell you they should have just held it the whole time?
[06:13] <poolie1> that could be good
[06:13] <spiv> Right.
[06:14] <poolie1> what happened on bug 437626 btw?
[06:14] <spiv> All I know is in the bug comments: basically, I'm still stumped.  We really need a way to reproduce it.
[06:16] <spiv> No random combinations of fetching stacked and unstacked branches into a shared repo triggered it for me, and none of the commands that crashed for the various affected users crash for em.
[06:17] <garyvdm> Hi all.
[06:17] <garyvdm> Do the new windows installers come with a ssh agent, or do I need to install one?
[06:18] <poolie1> ok
[06:18] <poolie1> i asked if it's reproducible and if so to give us a tarball
[06:18] <poolie1> garyvdm: i'm not sure but i think they don't
[06:20] <naoki> Hi, all.
[06:20] <poolie1> hello
[06:21] <naoki> My company is going to start using bazaar now.
[06:22] <naoki> repository layout is: /home/bzr/repos/<shared-repo-name>/<branch-name>
[06:22] <naoki> We want to backup this repos.
[06:23] <naoki> And I don't want to use rsync, because rsync copies even if repo is broken.
[06:23] <igc> hi garyvdm
[06:23] <garyvdm> Hi igc
[06:23] <naoki> Is there easy backup way based on "bzr pull"?
[06:24] <igc> naoki: is the repo-push plugin the sort of thing you're after?
[06:25] <naoki> https://launchpad.net/bzr-repo-push
[06:25] <naoki> good!
[06:26] <igc> naoki: I haven't used it myself but it sounds a good match
[06:26] <naoki> I'll try it.
[06:27] <poolie1> hi igc
[06:28] <igc> hi poolie1
[06:30] <igc> poolie1: http://bazaar-vcs.org/Roadmap?action=diff
[06:30] <igc> I like the last line :-)
[06:31] <poolie1> :)
[06:31] <poolie1> so igc, what are you working on this week?
[06:32] <igc> poolie1: until yesterday, doc and website polish
[06:32] <igc> today I need to fix the keywords plugin to use that hook we added for it
[06:32] <poolie1> hm
[06:33] <igc> right now, I'm grabbing a branch of lp so I can test my faster-log-file patch on that as jam/you requested
[06:33] <poolie> i think i'd prefer if you could work on some core bugs first
[06:33] <igc> in summary, clearning backlog
[06:33] <igc> poolie: sure. fire away
[06:34] <poolie> maybe bug 441126
[06:34] <poolie> no, bug 441125
[06:40] <garyvdm> It seems the windows installer comes with paramiko, but I'm not sure how to point it to my private key.
[06:42] <naoki> Do you using pageant?
[06:45] <garyvdm> naoki: I was not. I thought paramiko was an agent. I am now, and it's working.
[06:46] <naoki> I use paramiko with pageant always. But I think paramiko can work with $HOME/.ssh/config.
[06:47] <naoki> Host hostname
[06:47] <naoki>     IdentityFile  path_to_identity_file
[06:52] <naoki> Hmm, I'm sorry. I tried it but I can't.
[06:53] <poolie> garyvdm: i don't think paramiko is an agent
[06:53] <poolie> it can be a client of pageant
[07:00] <poolie> spiv could i persuade you to put bug numbers in your branches?
[07:00] <spiv> poolie: in the branch names?  Sure.
[07:00] <poolie> yes
[07:06] <vila> hi all
[07:10] <poolie> hello vila
[07:13] <igc> hi vila
[07:13] <igc> poolie: I'm having trouble reproducing bug 441125
[07:14] <igc> I can't run 'bzr reconcile remote-url' because it's read-only to me
[07:14] <igc> if I branch locally and run reconcile, it works fine
[07:15] <igc> can I grab the branch as a set of files somehow?
[07:16] <spiv> igc: grab them via SFTP?
[07:16] <spiv> lftp should be able to recursively fetch the .bzr directory.
[07:18] <poolie> good idea
[07:18] <poolie> it does seem to have been hit a few times
[07:18] <poolie> in that there were a few dupes
[07:26] <igc> poolie: right. All are are reported by scott on upstart branches though so it's possibly the same data(?) problem
[07:26] <igc> s/are/three/
[07:26] <poolie> true
[07:26] <poolie> i don't know why he sent three reports
[07:26] <igc> different files in different branches
[07:27] <poolie> was he just mad about the error, or just being cautious in deduping?
[07:27] <poolie> probably the second
[07:27] <spiv> I'd guess the second.
[07:27] <igc> me too
[08:10] <poolie> ok, good night...
[08:10] <vila> good night poolie
[08:11] <spiv> poolie: good night
[08:11] <RenatoSilva> Is there a way to 'extrac' a committed merge, as it was not a merge but a single commit?
[08:12] <bialix> hello all
[08:12] <vila> RenatoSilva: bzr diff -c<revno> ?
[08:12] <vila> hi bialix
[08:12] <bialix> bonjour vila :-)
[08:12] <RenatoSilva> vila: sorry?
[08:13] <RenatoSilva> vila: how to apply the diff
[08:13] <bialix> bzr patch
[08:13] <RenatoSilva> vila: and how to remove merge meta-info
[08:13] <vila> bzr merge -c<revno> ; bzr revert --pending-merges ?
[08:13] <RenatoSilva> bialix: if I bzr uncommit, when I commit again it'll know it's a merge
[08:14] <vila> what's wrong with that merge ?
[08:14] <RenatoSilva> vila: bzr merge? it's already emrged!
[08:14] <RenatoSilva> vila: I didn't say something's worng with the merge :)
[08:14] <bialix> sorry RenatoSilva, I've wedged to your conversaton without realizing context
[08:15] <vila> RenatoSilva: no, you didn't say, but somehow, I was under the impression you wanted to nuke it :)
[08:15] <vila> bzr uncommit ; bzr revert --pending-merges ?
[08:15] <vila> bzr st
[08:16] <RenatoSilva> the actual problem was that I did a bzr send at work, to bzr pull + push at home. But before this last I pushed new revisions in trunk, so I had to use bzr mergel rather than bzr pull
[08:16] <vila> RenatoSilva: try issuing 'bzr st' before and between all commands to see what happen
[08:16] <RenatoSilva> what's st?
[08:16] <vila> bzr status
[08:17] <RenatoSilva> ok, will --pending-merges keep the file changes though?
[08:17] <vila> RenatoSilva: yes, experiment in a side branch if you prefer
[08:17] <RenatoSilva> ok brb
[08:17] <vila> RenatoSilva: oops, --forget-merges not --pending-mergees
[08:18] <vila> RenatoSilva: 'bzr help revert' for more
[08:18] <RenatoSilva> ok just saw it
[08:19] <RenatoSilva> vila: workred fine \o/ love you! haha
[08:23] <RenatoSilva> vila: thank you!
[08:23] <vila> RenatoSilva: Always happy to help (TM) :D
[08:23] <RenatoSilva> bialix: I wanted to know bzr patch anyway, thanks
[08:45] <RenatoSilva> how to run a diff between two branches?
[08:45] <RenatoSilva> or between last revs from each one
[08:45] <Lo-lan-do> bzr diff $branch1 --new $branch2
[08:46] <vila> RenatoSilva: bzr diff --old <other-branch> or bzr diff --new <other-branch>
[08:46] <RenatoSilva> ok
[08:46] <vila> RenatoSilva: for more details: 'bzr help diff' :-D
[08:46] <RenatoSilva> I'm not getting a normal result
[08:59]  * igc dinner
[08:59] <RenatoSilva> ok got it working now
[08:59] <RenatoSilva> thanks!
[09:33] <johnf> jelmer, lifeless: you about?
[12:24] <lifeless> moin
[13:44] <kevinbsmith> Greetings all. I'm trying to find details about bzr repo security features, like how hard it would be for an attacker to modify without being detected. I can't find any information on the bzr web site or in the FAQ. Can anyone point me to docs/articles about that?
[13:46] <Lo-lan-do> kevinbsmith: You can add GPG signatures to revisions.
[13:47] <visik7> what happen if I checkout a bzr repo inside another bzr tree ?
[13:47] <kevinbsmith> Lo-lan-do: yes, but from what I have read, it allows any valid sig, not only from a list of approved committers
[13:49] <kevinbsmith> Lo-lan-do: also, i would have thought that the sha1 revids would provide automatic protection against corruption
[13:50] <Lo-lan-do> kevinbsmith: I believe you could set a value for gpg_signing_command that would only trust one specific keyring.
[13:52] <kevinbsmith> Lo-lan-do: I haven't seen complete docs on the gpg_signing_command either, but mostly I would like to see a description of the built-in uses of sha1 digests
[13:52] <jderose> kevinbsmith: sha1 (or equiv.) checksum provide integrity checks, but can't prevent against tampering
[13:53] <kevinbsmith> jderose: My hope would be that if anyone modified existing code or an old commit, the sha1 would mismatch and the repo would be declared corrupted
[13:54] <Lo-lan-do> There's "bzr check" for that.
[13:54] <jderose> kevinbsmith: as for the bzr sha1, see `bzr help testament`
[13:54] <kevinbsmith> jderose: and that if someone added a new file, commit, or revision, it would either be ignored by our build process (because it wouldn't be on the trunk) or would quickly be detected as new code by any developer who did a sync
[13:54] <Tak> is there a reason bazaar explorer opens a console window?
[13:55] <jderose> kevinbsmith: yes, but an attacker can just modify the sha1sum also.... with a signature, key would need access to the private key to forge it
[13:56] <kevinbsmith> jderose: ok, so what I would love to see is a one-page explanation of what security features are built into bzr (sha1, check), and what is available (gpg, testament).
[13:56] <jderose> kevinbsmith: but i'm glad you are bringing this up as it's a feature i want in bzr also, to use as you're thinking: so a build process can authenticate the author(s).  ;)
[13:56] <kevinbsmith> jderose: I *think* it's secure enough, but my opinion doesn't matter, and honestly yours isn't of much help when I try to communicate with other team members about their concerns
[13:58] <jderose> kevinbsmith: bzr already has revision hashes and revision signing.  but as far as i know it doesn't have any built-in way to check these signatures.
[13:59] <kevinbsmith> jderose: even full docs about gpg signing would be helpful
[13:59] <jderose> kevinbsmith: the information is there, you just might need a little glue on your build server.  can anyone else comment on this?  last i knew there still wasn't anything like `bzr verify`
[14:00] <kevinbsmith> There used to be a page on the bazaar wiki about security...but it's gone now :(
[14:01] <kevinbsmith> The ideal would be a point-by-point response to this paper: http://www.dwheeler.com/essays/scm-security.html
[14:01] <jderose> kevinbsmith: the revision signing is easy: in ~/.bazaar/bazaar.conf,  just add "create_signatures = always"
[14:01] <jderose> like:
[14:01] <jderose> [DEFAULT]
[14:01] <kevinbsmith> (like the Aegis folks did, linked to at the very bottom)
[14:01] <jderose> # Other stuff you might have...
[14:01] <jderose> create_signatures = always
[14:02] <kevinbsmith> but that only requires any valid sig, not a sig from a known team member (as far as I can tell)
[14:02] <jderose> kevinbsmith: then when you `bzr commit`, it will automatically sign the revision (so using some kind of agent is helpfull)
[14:03] <kevinbsmith> so we would have to somehow go back and scan for unknown signers
[14:03] <jderose> kevinbsmith: like i said, bzr doesn't itself check the signatures... your build process will have to do that and you will have to provide it a list key keys from which signatures are accepted
[14:04] <jderose> kevinbsmith: its not do hard using the bzrlib API to scan through the list of signatures for all the revisions in a branch
[14:05] <kevinbsmith> i would still love to hear that sha1 would give us 90+% of the protection we actually want/need
[14:06] <jderose> kevinbsmith: i'd like to hear that i won the lottery.  ;)
[14:07] <jderose> all the sha1 can do is assert to the integrity of the repository, not the authors of the revisions
[14:07] <kevinbsmith> jderose: heh. but seriously, a little documentation about such a key part of the data format doesn't seem too much to ask. Even two sentences would help
[14:07] <kevinbsmith> jderose: right, but detecting unexpected changes would go a long way for us
[14:08] <kevinbsmith> jderose: and just knowing that the repo hasn't been tampered with would be a really good start
[14:09] <kevinbsmith> jderose: I think I'll file a bug against the docs
[14:09] <jderose> kevinbsmith: but how would you know a change was unexpected?  someone besides your trusted commiters could insert malicious revisions with perfectly good sha1sums.
[14:09] <jderose> yeah, more is needed in the docs
[14:09] <kevinbsmith> jderose: but they would show up as a new commit, and i code review all commits
[14:10] <kevinbsmith> jderose: and there are only 2 of us, so I know what work is being done at all times
[14:10] <jderose> but the commands to look at are `bzr sign-my-commits` and `bzr testament`
[14:10] <jderose> and the "create_signatures = always" config variable
[14:12] <jderose> kevinbsmith: well, i guess they'll show up as new commits either way.... if you are reviewing all the commits and just want a way to make sure nothing slips by, using branches can accomplish what you want:
[14:13] <jderose> bzr uses a hierarchical history (one of its best features, IHMO).
[14:13] <kevinbsmith> jderose: but so far I have no evidence that if an attacker modified files directly in the repo that the corruption would automatically be detected
[14:14] <jderose> so when you `cd my_branch; bzr merge ../other_branch` for example, first it will just change the working tree... nothing is commit yet
[14:15] <jderose> is the repo something you control physically? if not, you need signatures, otherwise there is no way to know it wasn't changed (unless you store the past revision checksums in some trusted place to compare)
[14:16] <jderose> so i guess my final advice is: i don't think bazaar has a verification command yet, but i can create the signatures easily and you can create a verification command yourself without too much work
[14:17] <jderose> kevinbsmith: just put "create_signatures = always" in your bazaar.conf in the [DEFAULT] section
[14:18] <jderose> kevinbsmith: unless maybe i'm still not quite getting what you're after.  ;)
[14:19] <kevinbsmith> jderose: i still think bzr has/does what we need, but really need a statement from one of the authors to that effect. And I need to know under what circumstances an attack would automatically be detected, or what commands to run when in order to manually detect a problem.
[14:19] <kevinbsmith> jderose: I appreciate your answers
[14:20] <jderose> lifeless:  does bzr have a command yet to verify revision signatures?
[14:20] <pickscrape> Hi, can anyone point me at documentation on how to package a bzr plugin for ubuntu/debian?
[14:21] <jderose> pickscrape: i would look at one of the existing packaged plugins, like bzr-builddeb
[14:24] <jderose> kevinbsmith: np. hope you find the solution you're looking for.
[14:26] <pickscrape> Hi, can anyone point me at some documentation on packaging a bzr plugin for ubuntu/debian?
[14:26] <jderose> pickscrape: i think you dropped before getting my reply: (07:21:46 AM) jderose: pickscrape: i would look at one of the existing packaged plugins, like bzr-builddeb
[14:27] <pickscrape> jderose: aha, I didn't see my original message go through, hence me restarting my client and reposting :) Thanks for replying again.
[14:28] <jderose> np.  in my experience, following the example of a similar package is usually the best way to start a debian/ubuntu package
[14:28] <pickscrape> I tried that with bzr-svn but didn't see anything in the source about actually packaging the plugin. I'll have a look at bzr-builddeb and see what I can pick out.
[14:28] <gioele> hello
[14:29] <kevinbsmith> jderose: I just created launchpad bzr bugs 445434 and 445428 requesting better docs
[14:31] <jderose> pickscrape: do you mean packaging at the Python distutils/setuptools level, or the Debian level?
[14:31] <pickscrape> jderose: I want to create a .deb of a bzr plugin.
[14:32] <jderose> pickscrape: have you done any Debian/Ubuntu packaging before?
[14:33] <pickscrape> jderose: I haven't... I've looked around a bit and currently feel like someone who can't swim very well being told to jump into the deep end of the pool :)
[14:34] <jderose> well, the first step is a large one.  using bzr-builddeb as an example, you pretty much just create a debian/ directory like it has, but with some details changed to fit your package.
[14:35] <jderose> pickscrape: so next question, have you done any python distutils/setuptools packaging?
[14:36] <pickscrape> No, the closest I've ever been to was some gentoo ebuilds. I've never done any binary packaging before.
[14:36] <gioele> are there compiled .deb or PPAs for Dulwich (needed by bzr-git)?
[14:38] <jderose> pickscrape: for any Python stuff, packaging first using distutils is a good idea because it allows anyone to install it if they have Python (which they need anyway).  see http://docs.python.org/distutils/index.html
[14:38] <pickscrape> Ah, that's what produces eggs right?
[14:39] <jderose> pickscrape: for the Debian package, you're pretty much putting some extra meta-data in debian/ and telling it to call your setup.py script
[14:39] <jderose> pickscrape: yes, and it also can build, install, and make release tarballs for your Python package
[14:40] <pickscrape> jderose: thanks a lot for your pointers, much appreciated.
[14:40] <jam> morning lifeless and vila
[14:41] <vila> morning jam !
[14:41] <pickscrape> jderose: I do have one more question though... Do the installers target a specific python version or are they able to install to whatever version is installed on the machine being installed to?
[14:42] <jderose> pickscrape: normally they will install under what ever version of Python you run setup.py under
[14:42] <jderose> you can pick the system default with "#!/usr/bin/env python"
[14:44] <pickscrape> If they install to whatever version of python is installed, then that is ideal. We have people running anything from 2.4-2.6 and I'd rather not have to package for each individually :)
[14:44] <pickscrape> jderose: thanks again for your help.
[14:44] <jderose> np.
[15:04] <awilkins> jelmer: How's bzr-svn at detecting SVN merges?
[15:07] <awilkins> I'm really missing that "copy" feature that bzr lacks now.... copied some large files so I could copy a new released version of them in the SVN tree.. I'm guessing that's part of the large download I'm seeing and the rest is probably because the merge I did is being taken as a plain commit.
[15:18] <jam> awilkins: from what jelmer has said before, merges in svn are generally 'cherrypicks' and so they aren't represented in bzr-svn
[15:18] <jam> since bzr itself doesn't do a lot with a cherrypick
[15:19] <awilkins> jam: Yes... I thought SVN had improved this and had some merge properties now. I shall take a squizz at the properties on the relevant revision
[15:20] <jam> awilkins: they *do* have an 'svn:merge' property
[15:20] <jam> which has stuff like "merged: 200-210,212,214,218-300"
[15:20] <jam> however
[15:21] <jam> 1) I don't think it applies to the whole tree underneath that point
[15:21] <awilkins> Not necessarily
[15:21] <jam> 2) It easily allows non-contiguous ranges, which means that in bzr they would look like a cherrypick
[15:22] <awilkins> Yes, I think it could work for a subset of cases
[15:22] <awilkins> I think mine is probably one of the ones that could work, but I appreciate the problem
[15:22] <jam> awilkins: anyway, AFAIK bzr-svn ignores the values because of the problems
[15:22] <awilkins> I wish now I'd done the merge locally
[15:22] <jam> jelmer would have to give details
[15:23] <awilkins> And pushed it up to the server... was trying to save their repo space by copying some large text resources that have some differences between versions.
[15:24] <awilkins> I should just make the damn build process more sophisticated and get different versions of the resources by manipulating the VCS
[15:24] <awilkins> But they are all using SVN (in a contracted CollabNet server, no less), and I'm the maverick using bzr
[16:16] <CaMason> hi guys. I just did bzr shelve, followed by bzr unshelve, and I've got an error saying "The file id xxx is not present in the tree"
[16:20] <CaMason> I've got a number of changes that were shelved and I need to get them back :'(
[16:24] <vila> CaMason: 'bzr version' says ?
[16:24] <CaMason> 1.13.1
[16:24] <vila> hmpf, shelve was still part of bzrtools then ?
[16:24] <CaMason> I have no idea :o
[16:24] <vila> bzr help shelve
[16:24] <CaMason> says nothign about 'tools'
[16:24] <vila> ok, so it was already part of bzr core
[16:24] <vila> CaMason: I'm pretty sure that has been fixed in 2.0
[16:24] <vila> CaMason: what os/version are you using ?
[16:24] <CaMason> This is Ubuntu 9.04. This was installed via apt
[16:26] <vila> CaMason: https://launchpad.net/bzr  look at https://launchpad.net/~bzr/+archive and follow the instructions to update your package sources
[16:26] <CaMason> will this help me get back my changes?
[16:27] <vila> CaMason: it should allow you to use 'bzr unshelve' and get back your changes yes
[16:27] <CaMason> ok good :)
[16:27] <vila> CaMason: I'm 90% confident...
[16:29] <CaMason> ok, updates appearing in my update manager. Installing
[16:30] <jelmer> awilkins: jam's comments are correct
[16:30] <jelmer> awilkins: svn only has a notion of cherrypick merges
[16:30] <jelmer> awilkins: even if you do a 'full' merge it's stored as a series of cerrypicks
[16:34] <awilkins> jelmer: Bah. How's the rename support... I know that it can't assume that copied + deleted is a rename (from the SVN > BZR direction) but does bzr-svn manage to translate it's renames into copy + delete from BZR > SVN - It's trying to upload an awful lot of data for just "this node is now this node and this one is dead".
[16:36] <CraigMason> had a random BSOD :o
[16:38] <awilkins> jelmer: I tried to work it out from reading the code... then tried to do a quick test... ran into the "older libraries" thing, and a minor bug in URL parsing (merge later)
[16:41] <awilkins> jelmer: Ok, confirmed it does the copy+delete thing properly
[16:42] <awilkins> jelmer: Still doesn't explain to me why it uploads 10s of MB when I rename a few large text files ( multi-MB text files)
[16:51] <awilkins> Hang on, it's not a bug in the bandwidth bar is it?
[16:53] <awilkins> There's no way it's hitting the speeds it says it is, or that it's uploaded 750MB in less than 2 mins
[16:54]  * awilkins lets upload finish and checks server log, which is correct *phew*
[17:16] <Tak> shouldn't rebase have a --force option?
[17:16] <NET||abuse> hmm, trying to push back up from a branch on an eeepc to a bigger laptop.  the ip of big laptop was x.x.x.26   but i switched it over to a new ip int he network,, how do i overwrite the :parent address?
[17:16] <NET||abuse> my push line is bzr push --remember :parent
[17:16] <NET||abuse> so i need to reset :parent to the new address.
[17:28] <jelmer> tak: what would --force do?
[17:28] <Tak> allow you to rebase when you have local changes
[17:28] <Tak> ala merge --force
[17:29] <Lo-lan-do> NET||abuse: bzr pull --remember $newaddress
[17:29] <jelmer> Tak: rebase works in the local working tree
[17:30] <jelmer> tak: so it would have to back that up somewhere
[17:30] <Tak> hmm
[17:30] <Tak> shelve/unshelve?
[17:30] <jelmer> Tak: yeah, I guess it could do that under the covers
[17:31] <NET||abuse> Lo-lan-do, ahhh, very smart,,, I actually had just altered my .bzr/branch/branch.conf file.
[17:31] <NET||abuse> or whatever that conf file is called.
[17:31] <NET||abuse> thanks though..
[17:31] <NET||abuse> good to know alternate wya.
[17:32] <Lo-lan-do> I'd like to see a command-line interface to set/unset/modify the "related branches" settings though.
[17:35] <NET||abuse> Lo-lan-do, yeh, i was thinking there was nothing coming up in the command line reference about those types of methods.
[17:36] <NET||abuse> aliases serve the function of giving you locations to name, but just hte defaults are set and not alterable without transaction it seems.
[17:37] <Lo-lan-do> Yes.
[17:52] <beuno> jelmer, hi. Are you OK if I upgrade bzr-stats to 2a?
[18:34] <james_w> cgit isn't very pleasant to use
[18:34] <james_w> better than some, and quick, but less productive overall IME
[21:04] <jelmer> beuno: yeah, go ahead
[21:04] <jelmer> beuno: and thanks :-)
[21:05] <beuno> jelmer, thanks. I'm playing around with it so you can see only mainline commit counts, or second, third, fourth level, etc
[21:05] <beuno> (second level is to get around PQM hogging all the commits)
[21:06] <jelmer> beuno: ah
[21:08] <beuno> abentley, how do you feel about upgrading hitchhiker?  :)
[21:08]  * beuno wants his shared repo with bzr stuff again
[21:10] <vila> beuno: You should definitely play a bit with qlog to see some nice graphs
[21:10] <beuno> vila, I should give it another go, for sure
[21:15] <abentley> beuno: upgrade how?
[21:15] <beuno> abentley, to 2a
[21:17] <kfogel> abentley: is there any bzr access method that is resumable?  (I.e., picks up where it left off?)
[21:17] <abentley> kfogel: No.
[21:17] <kfogel> abentley: thank you.
[21:17] <abentley> kfogel: Did you see jam's message where he suggested doing smaller pulls instead?
[21:17] <kfogel> abentley: this is in the getting launchpad thread?
[21:18] <jam> abentley: I think it was just a direct email and not on a mailing list
[21:18] <kfogel> abentley: I'm in "Running rocketfuel-setup and getting launchpad" on launchpad-dev@.
[21:18] <jam> kfogel: I'll forward it to you
[21:18] <kfogel> jam: thank you.
[21:18] <jam> kfogel: sent
[21:19] <kfogel> jam: excellent, thx.
[21:19] <abentley> beuno: I'll think about it.  It's sometimes used as a recovery tool, so backwards-compatibility might be more important.
[21:20] <abentley> beuno: You can certainly pull it into a 2a repository, even before I switch.
[21:20] <beuno> abentley, it seems to be no-rr
[21:20] <abentley> beuno: You mean it won't convert on the fly?
[21:21] <beuno> abentley, yeap, bzr gets angry when you try to branch a non-rr into a rr shared repo
[21:21] <jam> beuno: it shouldn't
[21:21] <jam> I do it on the windows host
[21:22] <jam> build host
[21:22] <jam> it gets angry the *other* way
[21:22] <jam> rr => non_rr shared repo
[21:22]  * beuno checks his setup
[21:22] <jam> now, you can't contribute patches from your rr repo back to the non-rr project
[21:22] <beuno> AH
[21:22] <beuno> you're right
[21:22] <beuno> my previous setup did not work
[21:23] <beuno> so, ignore me then
[21:24] <alchemist__> I am seeking some advice on how to set permissions on a linux shared repository host so that everyone can read the repo - only certain users can merge to trunk - and other users can only merge to branches - is there any documentation on this?
[21:24] <kfogel> jam: your mail is great, I'm quoting it in a reply, but wondering why you didn't just follow up to all with it in the first place?
[21:25] <jam> kfogel: I did, everyone didn't include the list
[21:25] <jam> kiko sent it to me and aaron specifically
[21:25] <kfogel> jam: ah
[21:25] <kiko> kfogel, I'm confusing that way sometimes
[21:25] <jam> I'm not on LP-dev anyway
[21:25] <jam> and it would have been bounced
[21:25] <kfogel> jam: np
[21:26] <kfogel> kiko: s'okay, I can just be Human Mail Relay
[21:54] <luke-jr_> jelmer: bzr-svn refuses to branch now :(
[21:54] <luke-jr_> after I sanitized the Svn layout
[21:55] <luke-jr_> nm, found a config thing I didn't update
[22:17] <Oli``> How do I rollback one file?
[22:18] <vila> Oli``: 'bzr alias rollback=revert' and 'bzr rollback file' or just 'bzr revert file'
[22:21] <Oli``> vila: and that just takes the file backwards one revision?
[22:21] <Oli``> (well to the last revision it was edited)
[22:22] <vila> Oli``: yes, alternatively you can use 'bzr shelve' and chose which modifications you want to keep in the file and which you want to.. shelve
[22:22] <vila> err, I meant 'bzr shelve file'
[22:23] <vila> Odd_Bloke: but look at 'bzr help shelve' 'bzr help revert'
[22:23] <vila> Oli``: but look at 'bzr help shelve' 'bzr help revert'
[22:23] <vila> Odd_Bloke: sorry, blame xchat :-/
[22:37] <dereine> is it possible to branch and checkout in the same directory like on git?
[23:17] <Noldorin> hello. how can i use the --filters option on bzr export?
[23:30] <maxb> Hi, how does bzr handle interrupted network connections during pulls? Is it able to make use of the data it transferred already, or will it start again from the beginning
[23:31] <spiv> maxb: it generally starts again from the beginning :(
[23:32] <maxb> Ah. There's a discussion going on on the Launchpad mailing list about whether there should be a nightly tarball to help people on dodgy connections do the initial bulk transfer
[23:35] <Noldorin> hmm. why is bzr export silently failintg when i specify a DEST?
[23:36] <wgrant> maxb: Did you see the suggestion on the list to do a gradual pull?
[23:40] <mneptok> wgrant: that got filtered as porn by SpamAssassin
[23:49] <maxb> oh, now I do