[00:00] <mwhudson> i'm thinking the linux kernel is probably a little ambitious for the moment...
[00:05] <RAOF> mwhudson: Banshee would work.  That's ~20Mb or so of git.  Or is that not medium enough?
[00:05] <mwhudson> RAOF: let's try it
[00:05] <mwhudson> RAOF: url me up?
[00:05] <RAOF> Also has the advantage that I know bzr-git successfully branches it.
[00:05] <RAOF> git://git.gnome.org/banshee
[00:06] <mwhudson> oh right, all the gnome imports
[00:06] <RAOF> There's _lots_ of them available :).  You don't want one of them?
[00:06] <RAOF> libdrm would be another one.
[00:07] <mwhudson> RAOF: no, i'd just forgotten
[00:09] <lifeless> mwhudson: linux should work well with dev6
[00:09] <mwhudson> lifeless: until --default-rich-root is dev6 or similar...
[00:09] <mwhudson> (actually i think it will import into 1.9-rich-root now)
[00:15] <lifeless> spiv: I'm a little worn on repeated 'cut a round trip off' day days
[00:15] <lifeless> spiv: I had wanted to pair today, but my desktop blew a sprocket on saturday
[00:15] <lifeless> spiv: so perhaps tomorrow?
[00:16] <spiv> lifeless: sure, tomorrow sounds good to me.
[00:16] <jonnydee1> hi :) I recently stumbled over the following bug and reported it: https://bugs.launchpad.net/bzr/+bug/370551  Is there a chance that a fix will make it in a 1.14 maintenance release, or in 1.15, at least?
[00:17] <jonnydee1> bazaar cannot handle files that were moved to unversioned directories. but this makes the auto-detect feature more or less useless (for me, at least)
[00:18] <lifeless> jonnydee1: thats a dupe actually
[00:18] <lifeless> jonnydee1: no, 1.14 won't get a fix; its not a regression. You can just 'bzr add' the new directory before you move files into it, to avoid the bug.
[00:20] <lifeless> bug 367628
[00:20] <lifeless> thats the root cause
[00:20] <jonnydee1> lifeless: I know I can add the directory. But I need auto-detection when I refactor code using an ide. and there it happens often enough that files are moved to newly created directories....
[00:20] <lifeless> jonnydee1: in your example you manually move a file to the unversioned dir first
[00:27] <jonnydee1> lifeless: and how do I recover from the stack trace if I occasionally got trapped by this bug? Will it suffice to 'bzr add' the unversioned directory, afterwards?
[00:27] <lifeless> https://bugs.edge.launchpad.net/bzr/+bug/367628 is the main bug for 'bzr mv foo unversioned/'
[00:27] <jonnydee1> The problem is that 'bzr st' does not work anymore, which makes it hard to figure out what directories are needed to be versioned...
[00:28] <jonnydee1> lifeless: ok, should I mark the other bug report as a duplicate?
[00:28] <lifeless> no
[00:28] <lifeless> it may be slightly different
[00:28] <lifeless> I'm going to note that in the bugs
[00:29] <lifeless> my browser just stopped working for a minute, doing that now
[00:29] <jonnydee1> ok, thank you, lifeless, for your help :)
[00:31] <lifeless> no problem
[00:34] <lifeless> poolie: http://igotgenes.blogspot.com/2009/04/how-symbolic-on-removing-symlinks-in.html
[00:35] <poolie> hm that's good i guess
[00:36] <poolie> wbn if somebody fixed the bugs though :)
[00:36] <pygi> lifeless, poolie : will be nice to see you at UDS :)
[00:39] <poolie> you too
[01:54] <mwhudson> spiv: wow, bug 250451 gets nastier and nastier
[01:54] <spiv> mwhudson: yeah
[01:54] <spiv> mwhudson: I suppose LP could monkeypatch sys.stdout to autocorrect that message ;)
[01:55] <mwhudson> spiv: we _should_ translate paths in some exceptions
[01:55] <mwhudson> but i don't think that will help here
[02:09] <rocky> ugh, how many times do i merge stuff from another branch, forget to commit, do a bunch of work, and realize now i have my merge changes all messed up with my new work
[02:09] <rocky> is there an easy way to fix that ? ^^
[02:12] <thumper> shelve?
[02:12] <rocky> i've done a bunch of work, shelve will take me all night :(
[02:13] <mwhudson> shelve, redo the merge, commit, unshelve
[02:13] <mwhudson> ?
[02:13] <rocky> oh you mean shelve everything ?
[02:18] <AfC> What's with the alternating '>' and '<' in the pretty display when communicating with a remote server?
[02:18] <spiv> AfC: traffic direction
[02:20] <mwhudson> rocky: right
[02:20] <mwhudson> rocky: you'll might have to fix some conflicts when you unmerge, but hopefully not too bad
[02:20] <mwhudson> s/unmerge/unshelve/
[02:22] <AfC> spiv: oh
[02:22] <AfC> Is there a way to turn off the progress bar and just have the textual information?
[02:23] <rocky> mwhudson: wow, conflicts are huge (like whole files)
[02:26] <spiv> AfC: not that I know of.
[02:27] <mwhudson> rocky: :(
[02:27] <rocky> actually it wasn't so bad
[02:27] <rocky> it was just one file like that and the fix was easy enough
[02:27] <rocky> so yeah i'm all set now. .. thanks mwhudson! :)
[02:28] <AfC> spiv: I recall we talked about that here a while back - I guess I need to file a bug for that.
[02:28] <mwhudson> rocky: np
[02:28] <rocky> mwhudson: although for what it's worth, after shelving my stuff i had to "revert" the bzr merge that wasn't being committed before i could start over
[02:29] <mwhudson> rocky: hm, that makes sense
[02:29]  * mwhudson wouldn't know how shelve interacts with pending merges, i guess it just ignores them
[02:30] <rocky> well, bzr doesn't know that something special has happened with shelve so bzr stat still shows the pending merge, just with no changes
[02:30] <rocky> and you can still commit the pending merge with no changes
[02:30] <rocky> but obviously you don't want to, so just rever it
[03:02] <exeoeoe> http://3x3cut10n3r.mybrute.com/ <-- have fun & good luck
[03:11] <mwhudson> jelmer: are you going to be at uds?
[07:07] <vila> hi all
[08:04] <lifeless> signing off
[08:04] <lifeless> gnight
[08:08] <poolie> hello vila!
[08:09] <vila> good bight lifeless, hi poolie
[08:09] <vila> err night
[08:14] <poolie> vila, what are you working on next?
[08:14] <vila> bug #366107
[08:15] <vila> surprisingly, we can't handle servers which propose several auth schemes :-/
[08:16] <vila> then I'd like to refactor log tests and dig there, several bugs are hanging around since last Ian optimisations
[08:17] <vila> I'm also waiting for a review related to bug #355454 to finish fixing it
[08:22] <poolie> hm ok
[08:23] <poolie> 366107 sounds like a good thing to fix but i'm not so sure it's high priority
[08:23] <poolie> is it easy or already something you want to fix?
[08:24] <vila> poolie: should be easy once I enhance the related test servers and I'd like to fix it as not being able to handle server with multiple auth schemes is a bit embarassing :-}
[08:27] <poolie> ok
[08:27] <poolie> you probably know best
[08:28] <poolie> do you have an order of magnitude guess how long the log tests and fixes would take? like a week?
[08:30] <vila> surely less, it's first: refactoring existing ones that checks for particular revisions to avoid depend of the actual output format, then add new ones for the bugs I know of (mostly wrong selection of revisions)
[08:38] <vila> meh --coverage fails to recognize code run in threads :-/
[08:43] <spiv> vila: that's probably not too hard to fix
[08:43] <spiv> vila: add a call to threading.settrace in apply_coveraged in bzrlib/commands.py, probably
[08:47] <vila> spiv: works, great, thanks :)
[09:02] <mwhudson> vila: just in case you're curious, i'm adding support for multiple byte ranges to twisted's http server currently :)
[09:04] <vila> mwhudson: good, feel free to canibalize our http_server, there are some subtleties in parsing and validating the ranges requested
[09:05] <mwhudson> vila: no kidding
[09:05] <vila> :)
[09:07] <mwhudson> vila: twisted already had a pretty anal parser and handled the single-range case
[09:09] <vila> mwhudson: you may also want to have a look at lp:~vila/bzr/local-test-server for a quick way to validate your server against bzr
[09:57] <bialix> hi guys! anybody home?
[10:00] <bialix> I have a little question about English word "control" from "version control system". When you say "control" there you mean "management" or "check" or "watching"?
[10:02] <luks> I'd say management
[10:02] <bialix> hi luks
[10:02] <luks> hey
[10:02] <bialix> how are you?
[10:02] <luks> fine, thanks. you?
[10:02] <bialix> more or less
[10:03] <bialix> thanks for explanation
[10:03] <luks> well, that's just my opinion
[10:03] <bialix> my question raised because we have incorrect translation in Russian of this term
[10:03] <luks> and how I'd translate it to another language
[10:04] <bialix> I understand
[10:05] <bialix> translation in Russian is wrong because we have the word "control" here too, but it's false friend of translator
[10:05] <bialix> Russian control it's closer to "check"
[10:05] <luks> same here in slovak
[10:06] <bialix> :-)
[10:07] <bialix> I've started heavily using "daggy fixes" in my work
[10:07] <bialix> this very heavily influencing my style of work with VCS
[10:08] <luks> I don't think I could strictly follow that
[10:08] <luks> maybe for recent branches
[10:08] <luks> but definitely not for something old
[10:08] <bialix> well, in my case I need to maintain several branches in parallel, so it's work OK
[10:08] <bialix> and for old branches too
[10:08] <bialix> my mileage is different I suppose
[10:09] <luks> well, I'm a lazy person :)
[10:09] <bialix> me too, but daggy fixes make my life easier
[10:09] <bialix> because cherrypick in bzr sometimes painful
[10:10] <luks> the only feature I like in svn better
[10:10] <bialix> cherrypick?
[10:10] <luks> yep
[10:13] <bialix> IIUC this is inevitable downside of DAG-based systems
[10:14] <luks> exactly
[10:15] <jml> bialix: I'd say that the "control" part of VCS isn't terribly significant.
[10:15] <bialix> hi jml
[10:15] <bialix> jml: why not?
[10:15] <jml> bialix: "management" is close enough, I guess.
[10:16] <bialix> thanks
[10:16] <jml> bialix: but when I hear the phrase, I think "version $GENERIC_VERB $GENERIC_ABSTRACT_NOUN"
[10:16] <jml> version handler thing
[10:16] <bialix> :-)
[10:17] <bialix> ok, one more question: when you say "version" and "revision" -- what's difference?
[10:17] <bialix> VCS vs RCS
[10:17] <jml> not much.
[10:17] <jml> "version" has a connotation of "released version", I guess
[10:17] <bialix> version is more genric term?
[10:17] <jml> yeah.
[10:18] <jml> "revision" almost always refers to the result of a commit (in IT, anyway.)
[10:19] <bialix> I read "revision" as in "document revision"
[10:19] <jml> right, that's the broader sense
[10:19] <bialix> it's about editing the text, is not?
[10:19] <jml> a revision is what you get after you have revised something, usually a text.
[10:20] <bialix> i.e. when I fix some errors in the text?
[10:20] <jml> yeah.
[10:20] <bialix> or improve something?
[10:20] <bialix> thanks
[10:20] <bialix> the things much clearer now
[10:21] <bialix> it's so hard to translate VCS terms adequately
[10:21] <jml> I'll bet!
[10:21] <luks> doesn't russian have a commonly used equivalent?
[10:22] <bialix> that's the problem
[10:22] <bialix> we have some de0facto equivalent
[10:22] <bialix> de-facto
[10:22] <bialix> but sometimes they are represent svn-centric point of view
[10:22] <bialix> i.e. you have no pull/push in svn
[10:22] <davidstrauss> Revision is a bad term for VCS because it's colloquially used to mean a diff and the result of applying a diff.
[10:23] <luks> I think the the term applies to any vcs
[10:23] <bialix> davidstrauss: what will be better?
[10:23] <davidstrauss> bialix: commits should be called snapshots
[10:23] <luks> so if there were some manuals for csv or something, I'd use the term from there
[10:23] <luks> *cvs
[10:24] <davidstrauss> bialix: commits/revisions used to not be atomic, so you couldn't call them snapshots
[10:24] <bialix> luks: well, there is semi-official translation of svn
[10:24] <bialix> "svn book"
[10:24] <davidstrauss> bialix: but any modern vcs has atomic commits, so we ought to call them snapshots
[10:24] <luks> davidstrauss: but we don't :)
[10:24] <bialix> is not "commit" is the action
[10:25] <bialix> ?
[10:25] <bialix> but snapsot is the object
[10:25] <davidstrauss> bialix: See, that's another troublesome term
[10:25] <luks> depends, git uses it as the result of the action
[10:25] <davidstrauss> bialix: "Commit" can be the action of committing or the snapshot produced by committing
[10:25] <bialix> nice
[10:26] <davidstrauss> bialix: "Snapshot" is so unambiguous, I can even use it to define the confusing VCS terms.
[10:27] <bialix> I agree here
[10:27] <davidstrauss> bialix: It's a nice metaphor, too
[10:27] <luks> but it's not very translatable, I guess
[10:27] <davidstrauss> bialix: git could not call it a snapshot, though, because they have the staging area
[10:27] <luks> I can't think of a slovak translation for shapshot
[10:27] <bialix> for those who like photography?
[10:28] <davidstrauss> luks: What is the translation used for file system snapshotS?
[10:28] <bialix> for me snapshot is more about photo
[10:28] <luks> davidstrauss: I don't think there is one
[10:28] <davidstrauss> http://en.wikipedia.org/wiki/Snapshot_(computer_storage)
[10:28] <luks> we just use an expression to explain it
[10:29] <luks> can't think of a direct translation
[10:29] <davidstrauss> There are a few translations there in the inter-language links
[10:30] <luks> three words for russian :)
[10:30] <davidstrauss> It's pretty much impossible to find terms that work across languages. Computer terms are either metaphorical or made up
[10:30] <luks> so the same problem, I guess
[10:31] <luks> ah, no
[10:31] <davidstrauss> luks: I'm sure "commit
[10:31] <bialix> luks: in russian it's called "phot of file system"
[10:31] <davidstrauss> luks: I'm sure "commit" and "revision" are at least as bad
[10:31] <luks> davidstrauss: definitely
[10:31] <luks> I always laugh at the translation of commit in svn manuals
[10:31] <bialix> push is bad too
[10:31] <davidstrauss> luks: At least "snapshot" is unambiguous and tangible to English speakers
[10:32] <bialix> luks: in russian svn book "revision" called an "editing"
[10:33] <bialix> it's so crazy
[10:34] <bialix> davidstrauss: "git could not call it a snapshot, though, because they have the staging area" -- I disagree
[10:34] <bialix> their staging area is also "snapshotting"
[10:34] <davidstrauss> bialix: git isn't snapshotting anything
[10:34] <bialix> really?
[10:34] <davidstrauss> bialix: http://fourkitchens.com/blog/2009/02/03/importance-atomicity-or-why-git-staging-area-bad
[10:35] <bialix> looking into .git directory I see they're store actual state of the files
[10:35] <luks> davidstrauss: they are just applying a filter before they take the snapshot
[10:35] <davidstrauss> luks: no
[10:35] <luks> but I think it still is a shanpshot
[10:35] <davidstrauss> luks: nope
[10:35] <davidstrauss> luks: "Along these lines, one of the most atomicity-busting aspects of git’s staging area is that it doesn’t just mark code that needs to go into the next commit; it actually saves the hunk into the staging index. So, a developer could add code to the staging area, modify her working copy, and end up with a commit containing code that’s neither in her working copy nor in her stash."
[10:36] <davidstrauss> luks: Something can be in the git staging area but not in your working copy.
[10:36] <luks> hm, I didn't know that
[10:37] <davidstrauss> luks: It's uncommon for someone to stage a change, revert it, and then commit the staged change, but it's quite possible.
[10:37] <bialix> davidstrauss: roughly the same happens in interactive darcs commit
[10:37] <davidstrauss> luks: So, I think that violates the snapshot metaphor.
[10:37] <luks> davidstrauss: if you define it as a tree-level snapshot, yes
[10:38] <bialix> you mean the staging area is virtual, but real files are real?
[10:38] <davidstrauss> bialix: I mean a snapshot should be of your working tree
[10:38] <bialix> I understand
[10:38] <bialix> but...
[10:38] <luks> but the same thing applies to svn then
[10:38] <davidstrauss> bialix: A data structure that you stage changes into doesn't translate well to the snapshot metaphor
[10:38] <davidstrauss> luks: no
[10:39] <bialix> see! even in English you can use snapshot differently
[10:39] <davidstrauss> luks: svn allows selective commit, but the commit must be of files as they are in your working tree
[10:39] <luks> davidstrauss: they might be out of date
[10:39] <luks> davidstrauss: svn will automatically merge, if possible
[10:39] <davidstrauss> luks: svn requires you to update prior to commit if you're committing to changed files
[10:39] <luks> you can commit a revision that doesn't represent your working tree
[10:40] <luks> sure, but it doesn't have to be the modified files
[10:40] <luks> source code files usually depend on each other
[10:40] <davidstrauss> luks: if you mean "merge" different directories, then yes, svn sort of violates it. but the problem is more that svn doesn't distinguish between branches and directories.
[10:42] <davidstrauss> luks: svn takes snapshots from the directory you're in and below.
[10:42] <davidstrauss> anyway, it's way past my bedtime
[10:42] <davidstrauss> luks: I rag plenty on svn/git in that blog post, anyway
[10:43] <davidstrauss> luks: And I do bring up that very issue
[12:19] <Jemsquash> I think I'm missing something about bzr add.  I have a clearcase view where I do updates to. I have created a bzr repo here and I do an bzr move --auto, bzr add then I was hoping to do a commit. However I do a bzr status and it shows a lot of files and directories as unkown with a ?. I expected the bzr add to add these files. What am i missing?
[12:27] <lifeless> Jemsquash: have you done 'bzr init' at any point? if not I'd be expecting bzr mv and bzr add to be erroring
[12:27] <lifeless> Jemsquash: if they aren't erroring, perhaps you are invoking 'bzr add' in a strange way?
[12:28] <Jemsquash> I am just typing bzr add.
[12:28] <lifeless> what does it report?
[12:28] <Jemsquash> I have 3 revisions in the branch so it is definitely initialised.
[12:28] <Jemsquash> nothing.
[12:29] <Jemsquash> I do bzr add. The command completes with no response. I then do bzr status and it lists a load of files as unknown.
[12:30] <Jemsquash> I initially did an add and it seemed to add a bunch of files, but seemed to leave a whole lot out.
[12:30] <lifeless> would it be possible to pastebin?
[12:30] <lifeless> bzr st
[12:30] <lifeless> bzr add
[12:30] <lifeless> bzr st
[12:30] <lifeless> oh, actually
[12:30] <lifeless> I think I know
[12:30] <lifeless> if the things that are not getting added are all bzr trees themselves, that is why
[12:30] <lifeless> what does 'bzr info <somethingthatisn'tgettingadded>' report?
[12:31] <Jemsquash> I can't do it here, it was at work today and I don't have access to irc from there. Corporate firewalls :(
[12:31] <lifeless> I bet that the things you are adding are bzr trees,or perhaps svn or some other vcs that you have a bzr plugin for installed
[12:31] <Jemsquash> I'm a bit lost when you say that things not being added are all bzr trees themselves.
[12:32] <Jemsquash> Ok - perhaps.
[12:32] <Jemsquash> I'll have an investigation into looking for .svn folders or .cvs folders. It is a possibility although I will be surprised.
[12:32] <lifeless> to demo now
[12:32] <lifeless> cd /tmp
[12:32] <lifeless> bzr init foo
[12:32] <lifeless> cd foo
[12:33] <lifeless> bzr init bar
[12:33] <lifeless> bzr add
[12:33] <lifeless> bzr st
[12:33] <lifeless> you should see that bar hasn't been added
[12:33] <Jemsquash> yep. That sort of makes sense.
[12:33] <Jemsquash> Is that due to the shared repo containing branches etc?
[12:34] <lifeless> no, its because we haven't finished the nested trees support
[12:34] <Jemsquash> ah ok
[12:34] <lifeless> if it were to add bar, it would be versioning a link to bar, like a svn external
[12:35] <Jemsquash> I'm not sure I want to understand this concept of nested trees.
[12:35] <lifeless> heh
[12:36] <Jemsquash> it sounds scary :)
[12:36] <lifeless> its pretty straight forward; you have a bzr tree for a library or something that you want to embed in a larger tree
[12:37] <Jemsquash> so the tree in effect is a project with subprojects in a way.
[12:38] <lifeless> yes
[12:38] <Jemsquash> If you created a branch from a branch that contained a nested branch would it copy that nested branch with its revisions across too?
[12:39] <Jemsquash> I'm confusing myself with recursion when I reread my own post.
[12:41] <Jemsquash> I guess I'm asking what the relevance of the link is vs the actual full blown nested repository. The link is versioned not the nested repo.
[12:42] <Jemsquash> If I commit a change to the nested tree will it change the revno of the containing branch?
[12:43] <bialix> anybody knows approx timeframe for 1.15 release?
[12:45] <lifeless> the relevance is that you can continue working on the subproject separately [in an entirely different machine, without the parent project, for instance], then pull across into the subproject dir where you are nesting it
[12:45] <lifeless> if it was a new project, you've have to be doing merges, and it would be less conveninet
[12:45] <lifeless> bialix: sorry, not offhand
[12:45] <bialix> well, when UDS then?
[12:49] <Jemsquash> OK I think I understand. I would have to try it out to figure out how to use it. It sounds promising provided the overall project is structured correctly to cope with subprojects.
[12:53] <Jemsquash> Thanks for your suggestion on checking to see if the unadded files & directories are themselves under revision control.
[12:56] <bialix> UDS will be 25-29 May. So I suppose 1.15 will be before or after. right?
[12:57] <lifeless> bialix: I'm not exactly sure; I'd ask the list if you need to know
[12:57] <bialix> ok
[13:58] <phanatic> hi, i need to upgrade my branch to "rich-root-pack" to use split, right?
[14:05] <jelmer_> phanatic: yes
[14:05] <jelmer_> mwhudson: yes
[14:07] <phanatic> jelmer_: thanks. bzr upgrade --rich-root-packs should do the trick, right?
[14:09] <jelmer_> phanatic: if you're restricted to bzr <= 1.0, yes
[14:09] <jelmer_> phanatic: (1.9-rich-roots also exists, for example)
[14:10] <phanatic> jelmer_: any ideas why i get this: http://pastebin.com/d37856392 ?
[14:10] <jelmer_> phanatic: you must upgrade the repo, not the branch
[14:11] <phanatic> ah, thanks :)
[14:46] <Jemsquash> I'm trying to find an easy way of migrating from clearcase to bazaar. I've come across a tool that will migrate from clearcase to subversion. I could then import into bazaar from there. The tool that I found can be found at http://community.polarion.com/index.php?page=download&project=svnimporter Does anyone have any better suggestions in migrating to bazaar?
[16:22] <NfNitLoop> Jemsquash: I don't know about clearcase->svn, but svn->bzr is pretty easy.
[16:23] <NfNitLoop> The only thing I can think of is that you might lose some metadata in the clearcase->svn migration.
[16:23] <NfNitLoop> SVN doesn't do non-linear history.
[18:00] <limor> hi
[18:02] <limor> I have a question? any german people?
[18:23] <limor> the informations of an branch like history.. are they stored in the branch or in the repository folder?
[18:30] <Peng_> limor: The history is stored in the repository.
[18:31] <Peng_> limor: All .bzr/branch contains is some meta data and a pointer to the branch's tip revision, which can be used to reconstruct the history from the repository.
[18:37] <limor> ah ok so the branch .bzr folder only store the metadata an the .bzr in the repository filder stores the history where the branch points to
[18:51] <mrooney> I'm attempting to use loggerhead to view a remote svn branch, does anyone know if this should work?
[18:51] <mrooney> I am trying for example ./serve_branches svn+http://svnserver/repos/trunk
[18:53] <Peng_> mrooney: That's an interesting idea.
[18:53] <james_w> mrooney: does serve-branches load plugins?
[18:53] <Peng_> james_w: Yeah.
[18:53] <Peng_> It tells me "... is not a directory" though.
[18:54] <mrooney> do I need some switch to tell loggerhead it is a remote branch? maybe it has nothing to do with bzr-svn?
[18:57] <Peng_> From the file/class names, it seems filesystem-centric.
[18:57] <james_w> mrooney: serve-branches serves all branches under a directory, so that's probably not going to work
[18:58] <mrooney> oh darn and the repository doesn't work either
[18:59] <mrooney> I already have a full svn import of the repository, maybe I should add a commit hook to update it and then I can just use the local bzr thing
[18:59] <mrooney> although I bet it would be useful to others as well if it could work the aforementioned way
[18:59] <james_w> yep
[18:59] <james_w> loggerhead can do it fine
[19:00] <james_w> just serve-branches can't set it up in the right way it seems
[19:00] <james_w> is the other launch script still there?
[19:00] <james_w> start-loggerhead I think it was
[19:00] <james_w> or does serve-branches say anything about a config file in the source?
[19:00] <NEBAP> hi guys
[19:00] <beuno> no config file for serve-branches (yet)
[19:01] <mrooney> oh okay it works fine on my import
[19:01] <mrooney> but it doesn't have the fancy ajax expanding of changes or the unified diff / side by side toggle
[19:01] <mrooney> does LP have its own version or do I need trunk?
[19:01] <beuno> mrooney, trunk has those
[19:01] <mrooney> ah ok let me grab that
[19:01] <beuno> LP uses trunk
[19:01] <mrooney> fancy :)
[19:02] <beuno> we like cutting edges  :)
[19:03] <vxnick_> could I ask for your (collective) advise on something?
[19:03] <NEBAP> is it possible to use bazaar in the following way: I have a container folder which represents the complete project. Within this folder there are container subfolders representing a part (e. g. a DLL) of the project. Does bazaar recognise this project layout in the way that it knows that the subfolders are parts of the project container?
[19:03] <mrooney> hmm it looks the same to me
[19:03] <mrooney> I will take a look later
[19:04] <jelmer_> mrooney: I think I know
[19:04] <jelmer_> mrooney: loggerhead tries to store a cache in the branch
[19:04] <jelmer_> mrooney: and that might rely on local file access
[19:04] <jelmer_> beuno: ^
[19:05] <beuno> jelmer_, it does
[19:05] <beuno> well
[19:05] <beuno> not *in* the branch
[19:05] <beuno> in a /tmp dir
[19:05] <jelmer_> beuno: oh, ok
[19:05] <beuno> although, tbh, I don't know what it would do with remote branches
[19:05] <jelmer_> beuno: so that doesn't explain why ./serve-branches <svn-url> doesn't work
[19:06] <beuno> lifeless and I tried it on SVN branches locally, and it owrked
[19:06] <beuno> jelmer_, right. Other than "I have never tried that"  :)
[19:06] <beuno> it theory, it *should* work
[19:06] <vxnick_> what's the best way to deploy an app to a server with bzr? At the moment I'm using bzr-upload from my dev machine to the server itself, but I'm now wanting to centralise things so I can have a repository view on my project management system.
[19:07] <jelmer_> beuno: serve-branches:47 has a check that the specified path is a directory :-)
[19:07] <beuno> jelmer_, ah. There you go
[19:07] <beuno> because we do directory navigation
[19:07] <beuno> as well as branches
[19:08] <beuno> I guess we need a different path when it's already a branch
[19:08] <jelmer_> beuno: directory navigation could be done using Transport though
[19:08] <jelmer_> beuno: Transport.list_dir works on svn transports
[19:08] <beuno> jelmer_, interesting. May work better.
[19:08] <beuno> I guess that would be a bug
[19:09] <beuno> vxnick_, you could use push-and-update
[19:09] <beuno> and block .bzr dir from being served
[19:09] <vxnick_> beuno: thanks - does that push to the central server and then update the remote production server?
[19:09] <beuno> vxnick_, pushes and updates the working tree in the remote location
[19:09] <beuno> you need ssh
[19:10] <vxnick_> thanks, I'll take a look at its docs
[19:10] <beuno> welcome'
[19:10] <Peng_> Would using transports hurt Loggerhead's performance on local branches?
[19:11] <jelmer_> Peng_: it would have a very slight overhead
[19:12] <Peng_> BTW, Loggerhead does support remote branch references.
[19:12] <jelmer_> Peng_: not a noticable impact
[19:13] <Peng_> You can't pass a remote location to serve-branches, but if you have a branch reference locally, it works.
[19:13] <Peng_> Bit slow, though.
[19:19] <Peng_> beuno: It seems to build the caches correctly on remote branches.
[19:20] <jelmer_> bug 371787
[19:20] <Peng_> beuno: (Well, references, but that still loads the remtoe branch.)
[19:20] <beuno> ah
[19:20] <beuno> thanks herb
[19:20] <beuno> er
[19:20] <beuno> and jelmer_
[19:36] <mdz> I have a bzr repository which seems to fail to convert using bzr upgrade --1.9-rich-root
[19:36] <mdz> it runs for a very long time and never terminates
[19:50] <jelmer_> beuno, peng_: hmm, that was actually pretty easy
[19:50] <beuno> mdz, is .bzr.log helpful at all?
[19:51] <mdz> 66.413  Using fetch logic to copy between KnitPackRepository('file:///home/mdz/s
[19:51] <mdz> rc/.bzr/repository.backup/')(<RepositoryFormatKnitPack1>) and KnitPackRepository
[19:51] <mdz> ('file:///home/mdz/src/.bzr/repository/')(<RepositoryFormatKnitPack6RichRoot>)
[19:51] <mdz> 66.413  fetch up to rev {None}
[19:51] <mdz> 2654.157  Traceback (most recent call last):
[19:51] <mdz> [traceback from where I interrupted it]
[19:51] <mdz> so that's about 45 minutes with no indication of progress for most of it
[19:51] <beuno> mdz, if it's a big repo, I think it could actually take ages as it recompresses all it's deltas, etc
[19:52] <beuno> but it should be eating CPU like crazy
[19:52] <mdz> beuno: it did eat CPU, but the progress indicator didn't update
[19:52] <beuno> mdz, that's "normal"
[19:52] <beuno> how big is the repo?
[19:52] <beuno> I've heard big repos take up 18 hours in this kind of jump  :)
[19:53] <mdz> the repo is about 1.2G
[19:53] <Peng_> jelmer_: What was?
[19:53] <beuno> mdz, sounds normal then. Probably one of those things to do before you go to bed  :)
[19:55] <mdz> beuno: I will give it another try.  if it doesn't complete by this time tomorrow, I will renew my suspicions
[19:56] <jelmer_> Peng_: switching to transports
[19:56] <beuno> mdz, you should also be aware that all remote branches will need to be rich-root as well
[19:56] <beuno> or you won't be able to interact with them
[19:57] <mdz> beuno: that's what has actually triggered the upgrade for me; one of the branches I work with has converted and I could no longer branch from it
[19:58] <Peng_> jelmer_: Wait, did you actually do it, or just see how?
[19:58] <mdz> beuno: does this mean it's impossible to share a repository between branches unless they're all upgraded?
[19:58] <beuno> mdz, yes. It sucks.
[19:58] <mdz> beuno: or will upgrading the repository fetch massive amounts of data from remote branches?
[19:58] <mdz> hmm
[19:58] <beuno> mdz, they won't work if they aren't rich-root on the other end
[19:58] <beuno> but
[19:58] <mdz> sounds like I should quit using a repository
[19:58] <beuno> there's light at the end of the tunnel
[19:59] <beuno> 2.0 format will be rich-root
[19:59] <mdz> rather than spending days converting it
[19:59] <beuno> and there won't be any non-rich-root anymore
[19:59] <beuno> mdz, yeah, I keep them in shared repos between projects
[20:00] <vxnick_> is there anything like push-and-update but for commits?
[20:00] <beuno> vxnick_, well, checkouts accomplish that to some extent
[20:00] <beuno> but I don't know if push-and-update plugin works with it
[20:00] <vxnick_> beuno: I just want to avoid having to login to the production machine to update
[20:01] <jelmer_> Peng_: I actually fixed it
[20:01] <vxnick_> I want to do: local dev --> commit to central repo --> update remote production machine
[20:01] <Peng_> jelmer_: Oh, cool. :)
[20:01] <mdz> beuno: I just use one big repo for checking out everything
[20:01] <beuno> vxnick_, ah, two separate machines
[20:01] <vxnick_> beuno:  yup :)
[20:01] <beuno> mdz, yes, I used to do that. Had to move to per-project  :)
[20:02] <beuno> mdz, after 2.0, the madness should stop, and we can all finally be happy
[20:02] <beuno> vxnick_, I don't think there's anything in bzr that will let you do that
[20:02] <vxnick_> beuno: hmm. I think you're right but thought I'd ask
[20:02] <beuno> vxnick_, you can put together a plugin if you're good with python
[20:02] <beuno> vxnick_, or a cronjob  :)
[20:02] <vxnick_> beuno: I'm a complete noob :)
[20:03] <vxnick_> beuno: a cron is an option but it'd be nice to have it automated
[20:03] <mdz> beuno: if I just blow away my repo, will that break all of my local branches, or will they continue to work?
[20:03] <vxnick_> beuno: on second thoughts, it's probably best to manually run bzr update just in case there are any conflicts
[20:04] <beuno> mdz, break completely and loose all your data
[20:04] <mdz> beuno: sweet!
[20:04] <beuno> mdz, I'd recommend you branch from the repo for big branches so it's local and fast
[20:04] <mdz> so I guess I 1) make sure all my changes are pushed to LP, 2) blow away my repo, 3) re-download all my branches
[20:05] <beuno> and then bring in the rest remotely on a need-to-use basis
[20:05] <beuno> mdz, you can branch them locally instead, outside of the shared repo
[20:05] <mdz> beuno: oh, good idea
[20:06] <beuno> mdz, but then again, you're so close to the tubes, not sure it would make a dramatic difference
[20:06] <mdz> beuno: I'm at home, narrower tubes
[20:06] <beuno> right, avoid plumbing all together then
[20:08] <vxnick_> do you know of any bzr plugins to allow shell-type files to be run?
[20:08] <jelmer_> beuno, Peng_: how do I run the loggerhead testsuite?
[20:08] <beuno> jelmer_, nosetests
[20:08] <beuno> vxnick_, shell hooks. let me find some documentation for you..
[20:09] <jelmer_> beuno: is there some way to enter a debugger in case of tracebacks, like BZR_PDB=1 ?
[20:09] <vxnick_> beuno: thank you kindly :)
[20:09] <beuno> jelmer_, I... don't know   :)
[20:09] <jelmer_> beuno: thanks
[20:09] <vxnick_> beuno: I'm thinking that perhaps bzr upload would work if I called it from a shell script on the post_commit hook
[20:10] <vxnick_> from central server --> deployment server
[20:10] <mrooney> beuno: I checked out lp:loggerhead/trunk now and am running that, but I still don't see any of the new stuff LP has, do I need to do anything special?
[20:11] <beuno> mrooney, nope, you sould see all of it
[20:11]  * Peng_ has never run Loggerhead's test suite. Coughcough.
[20:12] <mrooney> beuno: hmph, I'm stuck then
[20:14] <beuno> vxnick, http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#using-hooks
[20:15] <beuno> http://bazaar-vcs.org/BzrHooks
[20:15] <vxnick> beuno:  cheers!
[20:15] <beuno> mrooney, did you install loggerhead from a package?
[20:15] <mrooney> beuno: no I checkout out lp:loggerhead/trunk and ran serve_branches
[20:16] <beuno> mrooney, do you didn't have it installed previously?
[20:16] <mrooney> beuno: well I had run 1.10 in the same way previously
[20:16] <beuno> mrooney, can you try getting lp:loggerhead instead?
[20:16] <mrooney> yeah that is what I originally used
[20:16] <mrooney> then I tried trunk and it looked the same
[20:17] <beuno> well, it's all there is  :)
[20:17] <mrooney> beuno: what is all there is?
[20:17] <beuno> mrooney, you don't have serve-branches in /usr/bin?
[20:17] <beuno> mrooney, lp:loggerhead
[20:18] <mrooney> beuno: nope I don't have it except in the 1.10 and trunk checkout
[20:26] <beuno> mrooney, so
[20:26] <beuno> you're doing:  bzr branch lp:loggerhead; cd loggerhead; ./serve-branches
[20:27] <mrooney> beuno: well, bzr co lp:loggerhead/trunk loggerhead-trunk; cd loggerhead-trunk; ./server-branches path
[20:28] <mrooney> well except for that typo in the last command
[20:30] <mrooney> is anyone able to attempt to reproduce it? as long as you have a local repository it should take about a minute
[20:30] <beuno> and when you hit localhost:8080
[20:30] <beuno> you get the old version?
[20:32] <mrooney> beuno: well I assume, I don't have the ajax expansions or side by side vs unified diff options
[20:32] <mrooney> if I kill the trunk process it stops working so I am fairly sure it is being served from the process I think it is
[20:34] <Peng_> Could it be importing the wrong "loggerhead" somehow? Does that even work anymore? I broke it for UserBranches, but I'm not sure about regular Branches.
[20:35] <mrooney> I would say it could have something to do with me first using the 1.10, but in retrospect I see lp:loggerhead goes to trunk anyway
[20:35] <mrooney> so I never actually had 1.10
[20:36] <mrooney> Peng_: do you have a repos to test with?
[20:37] <Peng_> mrooney: Test what?
[20:37] <mrooney> to see if someone else serving from trunk gets what I expect, the LP interface
[20:37] <mrooney> maybe they don't!
[20:56] <jelmer_> beuno, Peng_: loggerhead works on svn and git branches now :-)
[20:57] <beuno> jelmer_, you're unstoppable
[20:57] <beuno> have you files a merge proposal for the tweaks?
[20:57] <mrooney> jelmer_: so I can grab your branch and use a remote svn branch?
[20:57] <BasicOSX> just a /poke for input regarding 1.15rc1. My initial post had 1 follow-up and I've responded to that. Looking for general feel on the state of the code and bug fixes so a 1.15rc1 can be created.
[20:59] <jelmer_> mrooney: yeah, the last two branches I submitted for merging into loggerhead
[20:59] <jelmer_> mrooney: as well as the latest bzr-svn and subvertpy
[20:59] <jelmer_> beuno: and mercurial :-)
[20:59] <mrooney> ah okay I'll merge those locally
[20:59] <beuno> jelmer_, really?  bzr works with hg?
[21:00] <jelmer_> beuno: well enough for the history
[21:00] <jelmer_> beuno: I haven't tried looking at the diffs yet
[21:00] <beuno> amazing
[21:00] <jelmer_> mrooney: there's one caveat, you'll have to disable the caching in bzr-svn because loggerhead uses threads
[21:00] <beuno> jelmer_, if you point me at the MP, I'll review/merge
[21:00] <beuno> ah
[21:01] <beuno> Peng_ got to it  :)
[21:01] <beuno> he can merge
[21:01] <Peng_> beuno: OK.
[21:01] <jelmer_> beuno: https://code.edge.launchpad.net/~jelmer/loggerhead/transport/+merge/6179, https://code.edge.launchpad.net/~jelmer/loggerhead/transport/+merge/6179
[21:02] <jelmer_> I mean https://code.edge.launchpad.net/~jelmer/loggerhead/fix-nick/+merge/6180
[21:02] <Peng_> Huh, I haven't seen any code review emails. I'm still getting other LP mail...
[21:03] <LarstiQ> jelmer_: dude! asom!
[21:04] <Peng_> BTW: I don't want to review fix-nick, since I'm not qualified to comment on branch._get_nick.
[21:05] <Peng_> Ahh, here the emails are; they're just a bit late.
[21:06] <beuno> jelmer_, I had to change the nick bit so it didn't try and grab it remotely for checkouts
[21:06] <beuno> I think this will revert back to that behaviour?
[21:06] <beuno> or does the local=true prevent it?
[21:08] <jelmer_> beuno: local=True prevents it
[21:09] <beuno> jelmer_, thanks. Will merge it
[21:09] <Peng_> I could fix my review comments on transport and merge it. OK?
[21:10] <beuno> Peng_, go for it!
[21:10] <Peng_> OK.
[21:12] <jelmer_> Peng_: thanks!
[21:21] <mwhudson> jelmer_: what was i asking? :)
[21:21] <jelmer_> mwhudson: :-)
[21:21] <jelmer_> mwhudson: Where I would be at UDS
[21:21] <jelmer_> s/Where/Whether/
[21:21] <mwhudson> jelmer_: oh right
[21:21] <mwhudson> jelmer_: good!
[21:22] <jelmer_> mwhudson: more bzr-git issues to work on ?
[21:22] <beuno> jelmer_, you're going?
[21:22] <jelmer_> beuno: yep
[21:22] <beuno> yay
[21:22]  * beuno will be there
[21:22] <mwhudson> jelmer_: i can't quite remember why i was asking now :)
[21:22] <jelmer_> beuno: Cool :-)
[21:23] <beuno> Peng_, how about you?
[21:23] <mwhudson> jelmer_: testing git imports got stalled by having our staging code import machine stolen by IS
[21:23] <jelmer_> IS?
[21:24] <jelmer_> mwhudson: oh btw, I fixed another excessive memory usage issue in dulwich
[21:24] <mwhudson> information services
[21:25] <mwhudson> jelmer_: can i cope with the kernel yet? :)
[21:25] <beuno> aka, sysadmins
[21:25] <jelmer_> mwhudson: maybe
[21:25] <jelmer_> mwhudson: samba works pretty well now
[21:25] <mwhudson> jelmer_: cool
[21:25] <jelmer_> it's still a bit slow though, takes a couple of hours
[21:26] <mwhudson> jelmer_: importing into what?  --1.9-rich-root
[21:26] <mwhudson> jelmer_: hours!?! we have had cscvs imports take _days_
[21:26] <jelmer_> mwhudson: development6
[21:26] <mwhudson> o
[21:27] <mwhudson> k
[21:27] <jelmer_> mwhudson: the fact that creating an inventory in 1.9-rich-root is O(tree) makes it really slow
[21:28] <LarstiQ> slower than several hours you mean?
[21:28] <jelmer_> LarstiQ: yeah
[21:28] <jelmer_> you spent most of the time serializing and deserializing inventories
[21:28] <mwhudson> jelmer_: i can believe that
[21:28] <jelmer_> s/spent/spend/
[21:30] <Peng_> beuno: Me what?
[21:30] <beuno> Peng_, are you going to UDS?
[21:30] <Peng_> beuno: No.
[21:30] <Peng_> beuno & jelmer_: I merged the transport branch.
[21:30] <jelmer_> Peng_: Cool, thanks!
[21:31] <beuno> Peng_, you couldn't come?  or didn't get an offer to be sponsored?
[21:31] <jelmer_> mwhudson: what's the best way to get those OOo / samba branches updating again
[21:31] <jelmer_> mwhudson: ?
[21:31] <mwhudson> jelmer_: again?
[21:31] <Peng_> beuno: Um, let's say both. I don't even know anything about UDS.
[21:32] <jelmer_> mwhudson: Well, last time you asked tbm (?) to trigger an update
[21:32] <jelmer_> mwhudson: but doing it that way seems a bit labor-intensive :-)
[21:34] <beuno> Peng_, we should get you to one of them and hack  :)
[21:36] <mwhudson> jelmer_: spm
[21:36] <mwhudson> jelmer_: they've got stuck again?
[21:36] <Peng_> beuno: I dunno. I'm shy. And I dunno how useful I'd be. I still haven't done any major work. Plus I should've started eating dinner 20 minutes ago, and I'll go do that now. See you later, everyone. :) (Which is convenient for getting out of this conversation, but also true.)
[21:37] <beuno> Peng_, enjoy  :)
[21:39] <jelmer_> mwhudson: yeah
[21:39] <Peng_> Quick question: does transport.stat() follow symlinks?
[21:39] <jelmer_> mwhudson: but seem stuck even for smaller stuff, so it's impossible to use launchpad with reasonably large (>= 10k or something) development6 branches
[21:42] <mwhudson> jelmer_: two points i guess: 1) we should be able to make changes soon that allow us to up the timeout
[21:42] <mwhudson> 2) this means 15 minutes with no activity report -- that much be a bug somewhere
[21:42] <mwhudson> must
[21:43] <jelmer_> mwhudson: when does that timeout happen, during pull ?
[21:43] <mwhudson> jelmer_: yes
[21:44] <vxnick> what's the best way to move my repository including the ignored list?
[21:44] <mwhudson> jelmer_: also branch outside a shared repo is really slow for dev6, i guess this is an indication of the same problem
[21:44] <mwhudson> jelmer_: have you been having problems with mirrored branches too, or just hosted?
[21:45] <jelmer_> mwhudson: both
[21:45] <mwhudson> :(
[21:47] <LarstiQ> jelmer_: tbm is Martin Michlmayer :)
[21:47] <LarstiQ> vxnick: do you mean branch? Repositories don't have ignore lists.
[21:47] <vxnick> LarstiQ: sorry, that's correct
[21:48] <LarstiQ> vxnick: assuming the ignore list is nicely committed and everything, `bzr push` would be the operation of choice.
[21:48] <vxnick> LarstiQ: push doesn't move the files though does it, just the history?
[21:48] <jelmer_> LarstiQ: ahh
[21:48] <jelmer_> LarstiQ: Too many TLA's >-)
[21:49] <LarstiQ> jelmer_: there is only one tbm! ;)
[21:49] <LarstiQ> vxnick: the history is the important bit :)
[21:49] <LarstiQ> vxnick: a working tree can always be constructed if you have the history
[21:49] <LarstiQ> vxnick: where do you want to move it from, and whereto?
[21:49] <vxnick> LarstiQ: how so? I'm looking to shift the entire branch from my local machine to a remote server
[21:50] <LarstiQ> vxnick: does it even need a working tree then? Usually the answer is no.
[21:50] <vxnick> LarstiQ: but ideally I want to move the entire shared-repo
[21:51] <vxnick> LarstiQ: it does in this case as I want to have the files viewable through a system similar to trac
[21:51] <LarstiQ> vxnick: then you do not need a working tree.
[21:51] <LarstiQ> vxnick: the system like trac will provide it.
[21:51] <LarstiQ> vxnick: like, Loggerhead mwhudson, Peng_ and jelmer have been talking about.
[21:52] <vxnick> LarstiQ: thanks I'll have a read :)
[21:52] <LarstiQ> vxnick: for pushing an entire repo there is a repo-push plugin iirc (http://bazaar-vcs.org/BzrPlugins)
[21:52] <vxnick> LarstiQ: that looks ideal, many thanks!
[21:53] <LarstiQ> vxnick: np, let me know how it went
[21:53] <vxnick> will do
[21:54] <fullermd> q
[21:54]  * fullermd slaps his mouse.
[21:59] <vxnick> LarstiQ: worked a treat, thanks again :)
[22:00] <LarstiQ> vxnick: good :)
[22:08] <jfroy> jelmer: I just read a message you wrong on the mailing list where you mention push_merged_revisions. I'm not familiar with that setting, is it new?
[22:08] <jfroy> *you wrote
[22:13] <jelmer_> jfroy: no, it's been there for a while but never has been announced very publicly
[22:13] <jfroy> Am I guessing correctly that it pushes RHS revisions as separate svn commits when pushing a merge revision?
[22:14] <jfroy> *as separate svn revisions
[22:16] <jelmer_> jfroy: yes, onto a separate branch
[22:17] <jelmer_> or rather, separate branches
[22:17] <jfroy> I'm not sure I
[22:17] <jfroy> *I'm following completely.
[22:17] <jfroy> Are you saying it creates a new "branch" in svn?
[22:17] <jelmer_> jfroy: yes
[22:17] <jelmer_> and uses the bzr branch nick for the branch name in svn
[22:18] <jfroy> And I assume it guesses the bath based on its guess of the repository layout?
[22:18] <jelmer_> so if you did a commit in a bzr branch called "feature-a" and then merged it into trunk
[22:18] <jfroy> *the path
[22:18] <jelmer_> bzr-svn would push the commits in feature-a into branches/feature-a in subversion
[22:18] <jelmer_> and the merge commit onto trunk
[22:18] <jfroy> gotcha
[22:18] <jfroy> what happens if you pushed feature-a to svn yourself
[22:18] <jfroy> then merge feature-a into trunk (locally) and push trunk
[22:19] <jfroy> I assume, like any other bzr-svn push, that it will read the bzr-svn revprop and do the right thing?
[22:19] <jelmer_> jfroy: yes
[22:19] <jfroy> e.g. it will see it has no revisions to push, then move on to the merge revision in trunk
[22:19] <jfroy> I like it :)
[22:20] <jfroy> So where do I sign up for this goodness.
[22:20] <jfroy> bazaar.conf?
[22:21] <jelmer_> jfroy: yeah
[22:21] <jelmer_> or locations.conf / subversion.conf for individual repo's
[22:21] <jfroy> right, it's defined on BranchConfig which inherits from Config
[22:22] <jfroy> so it should pick up the usual behaviors of bzr's config machinery
[22:24] <jfroy> I think you should advertise it more.
[22:25] <jfroy> It's pretty nifty :p
[22:27] <jelmer_> I haven't used it much myself so it may still have some rough edges
[22:27] <jelmer_> I agree it's pretty nifty though :-)
[22:28] <jfroy> mmm
[22:28] <jfroy> Well if I hit any snags I'll file bugs, as usual.
[22:32] <jelmer_> thanks
[22:51] <flacoste> hi there
[22:51] <flacoste> i want to open a branch and look at the commit messages from a specific revision onward
[22:52] <flacoste> any pointers on how to use bzrlib to achieve this?
[22:52] <flacoste> i'm looking at log.py (but my head spins)
[22:52] <lifeless> moin
[22:53] <thumper> hmm...
[22:53] <mwhudson> log.py is pretty much brain-pain
[22:53] <thumper> merge sorted ?
[22:53] <flacoste> thumper: i don't know what this means
[22:53] <mwhudson> flacoste: all revisions, or just mainline?
[22:53] <thumper> flacoste: it wasn't for you :)
[22:53] <flacoste> just mainline
[22:53] <flacoste> lol
[22:53] <thumper> just mainline is easy
[22:53] <lifeless> flacoste: b = bzrlib.branch.Branch.open(url)
[22:53] <flacoste> yeah, i assumed so
[22:53] <lifeless> b.lock_read()
[22:54] <lifeless> revid = b.revno2revid(revno)
[22:54] <lifeless> for revid in b.iter_revision_history(revid):
[22:54] <lifeless>     print b.repository.revision(revid).message
[22:55] <lifeless> or ~ that anyhow
[22:55] <lifeless> iter_revisions or whatever its called is faster than getting inidividual revisions
[22:55] <flacoste> ok and this will return revision from revno and more recent?
[22:55] <flacoste> actually, excluding revno
[22:55] <flacoste> i assume
[22:56] <lifeless> oh, you want more recent
[22:56] <lifeless> iter_revision_history(b.last_revision)
[22:56] <lifeless> and then test for the exit point
[22:56] <flacoste> makes sense
[22:56] <flacoste> thanks a lot!
[22:57] <flacoste> how do i release the lock?
[22:57] <mwhudson> b.unlock()
[23:02] <ronny> LarstiQ: sup on the easy_install issues?
[23:02] <igc> morning
[23:04] <jelmer_> hi ian
[23:06] <flacoste> the only iter_ i find on branch is iter_merge_sorted_revisions
[23:11] <igc> hi jelmer_
[23:12] <thumper> igc: composite trees?
[23:12] <igc> thumper: back to reviewing them today
[23:12] <thumper> igc: cool
[23:12] <igc> thumper: sorry for the delay - just not well enough last week
[23:12] <thumper> ok
[23:15] <abentley> igc: IIRC, the big sticking point is the text filtering.
[23:15] <igc> abentley: hi. Right
[23:16] <igc> abentley: a parameter exists in the WT API but not the Tree one
[23:16] <abentley> igc: CompositeTree can contain RevisionTrees and WorkingTrees, but only the WorkingTree version supports text filtering.
[23:16] <abentley> igc: Why isn't that already causing problems?
[23:17] <igc> abentley: I'll think hard about it today. What problems would you expect?
[23:17] <abentley> igc: I would expect bzr cat -r -1 to raise an exception because an unknown parameter was passed into it.
[23:18] <abentley> igc: Where is text filtering actually used?
[23:18] <poolie> igc, i like your three/four wishes, but they're a bit big to be used there
[23:19] <poolie> by which i mean, i suppose, that "adoption blockers banished" could be just the only item on the roadmap for the whole duration of the project :)
[23:19] <poolie> but i suppose it's fine
[23:20] <igc> abentley: it's used implicitly most of the time
[23:20] <igc> abentley: and explicitly in some cases like cat and export
[23:22] <abentley> igc: So it defaults to True.  That's pretty gutsy.
[23:23] <igc> abentley: for WorkingTree's, it really needs to
[23:23] <igc> abentley: otherwise, every plugin needs to remember to switch it on
[23:23] <igc> and command
[23:24] <igc> abentley: IIRC, it used to live on the Tree API and default to True there too
[23:24] <abentley> igc: Not every plugin and command, just those that want the filtered form.
[23:24] <igc> abentley: but we backed out the change for .bzrrules, taking away historical storage of rules
[23:25] <abentley> igc: it's still a subtle enough behavior change that bugs it introduces might not be caught by our existing tests.
[23:26] <igc> abentley: in a sense, bzr has always used the internal form only
[23:27] <abentley> igc: I think that the parameter should exist on Tree, but should only affect Trees which have a filtered form.
[23:27] <igc> abentley: content filtering just means that what's in the tree is something else convenient for the user
[23:29] <igc> abentley: that sounds ok to me
[23:31] <igc> abentley: I'm pretty sure the text filtering issue was the only blocker wasn't it?
[23:31] <mwhudson> jelmer_: do you have a list of other branches that are failing to pull correctly?
[23:31] <abentley> igc: You gave me a tweak, and I upgraded it to resubmit because of that.
[23:32] <igc> abentley: I almost suggested last week that you land your change and we work together on the text filtering as a follow-up/known issue
[23:32] <jelmer_> mwhudson: lp:~jelmer/samba/trunk, lp:~jelmer/openoffice/trunk and lp:~jelmer/openoffice/hosted
[23:33] <igc> abentley: given how little the text filtering is currently used
[23:33] <jelmer_> mwhudson: beware of the last two though, they're both around 4.5Gb
[23:33] <igc> (and that's because we don't have branch-specific rules yet)
[23:33] <mwhudson> jelmer_: ah, the other two are mirrored branches
[23:34] <mwhudson> jelmer_: it's a bit crap that the openoffice/hosted got stuck again
[23:34] <mwhudson> jelmer_: did you push a lot of new revisions?
[23:34] <jelmer_> mwhudson: about 100k
[23:34] <abentley> igc: I'd be happy to do that.
[23:35] <mwhudson> jelmer_: ok, i guess that qualifies as a yes
[23:35] <jelmer_> mwhudson: :-)
[23:36] <igc> abentley: cool. Let's do that then because I don't think anything else I've seen in your patches so far will be affected
[23:37] <abentley> igc: I'm looking at the implementation of cmd_cat, and it doesn't pass filtered as a parameter to get_file_text.
[23:38] <igc> abentley: it's using the Tree API from memry, where that parameter doesn't exist
[23:38] <igc> abentley: RevisionTree API even
[23:39] <abentley> igc: It seems to be using revision trees everywhere, and in that case, it makes no sense to filter, because the file is already in the internal form.
[23:40] <igc> abentley: right, though the user can explicitly ask to see the output post-filtered
[23:40] <abentley> igc: Post filtered meaning the internal form?
[23:41] <igc> abentley: though, filtered then means "using configured filters", not historical filters
[23:41] <igc> abentley: the filtering can go 2 ways
[23:41] <igc> internal <-> external
[23:42] <igc> get_file_text() filters external -> internal
[23:42] <igc> abentley: in the case of cat, the filtering is the opposite way
[23:43] <abentley> igc: If "filtered" can mean two different states, do you think it would be clearer to refer to the desired state instead?
[23:44] <igc> abentley: perhaps
[23:44] <igc> abentley: the text at the top of bzrlib/filters/__init__.py might be of interest btw
[23:49] <abentley> igc: So this explains why no tests break even though CompositeTree doesn't support "filtered".  Nothing which uses CompositeTree is also providing that parameter.
[23:50] <lifeless> abentley: we're going to need CT everywhere right?
[23:50] <abentley> lifeless: No.
[23:50] <lifeless> where won't we?
[23:51] <lifeless> RevisionTree's for instance, shouldn't they be returned as CT's now?
[23:51] <igc> abentley: probably because nothing wants the external form, only the internal
[23:51] <Peng_> Possibly-dumb question: can branch references use relative paths?
[23:51] <lifeless> Peng_: not currently
[23:51] <mwhudson> Peng_: no
[23:51] <Peng_> Darn. Thanks.
[23:51] <abentley> lifeless: Most cases where we're writing to the tree, and cases where we handle nesting directly for read operations.
[23:51] <Peng_> That'd explain why I wasn't using a relative path already. :D
[23:51] <mwhudson> there was a thread about this on the bzr list semi-recently
[23:52] <lifeless> abentley: I'd have thought that e.g. 'bzr ls -R lp:twisted' should recurse.
[23:52] <abentley> lifeless: It probably should, but it's not on the list of commands I've committed to support.
[23:53] <lifeless> abentley: this comes back to my strong feeling we should be putting the support inside regular trees rather than an optional external construct which people need to remember to use
[23:55] <abentley> lifeless: I don't think that's practical.
[23:55] <lifeless> abentley: why not?
[23:58] <abentley> it makes everyone pay the cost of the feature, it makes recursion mandatory, it hides what's really going on, it makes the code trickier to debug.
[23:59] <abentley> It's an all-or-nothing sort of solution.  We need an incremental one.
[23:59] <abentley> If we can't start somewhere, we'll never get finished.