[03:30] <GungaDin> how can I know when was the last time a line in a file changed?
[03:30] <GungaDin> I tried bzr blame.. but not sure how ot access the revision I see
[03:31] <lifeless> bzr log -r 12.34.56
[03:32] <GungaDin> it says it wasn't in the branch
[03:33] <GungaDin> sorry, my mistake
[04:18] <Vornicus> How portable is a bzr repository?  If I create one on a flash drive, will it work on multiple computers and multiple platforms?
[04:20] <lifeless> it should
[04:20] <lifeless> we try pretty hard to make it portable
[04:20] <Vornicus> Yay!
[04:21] <spm> lifeless: huh, that's a cool achievement! the old 32bit machine vs 64bit machine (tho usually for me it was also x86 to sparc) shifting on 'binary' formats is a pita
[04:22] <lifeless> spm: because we work directly over the network on FTP, we're basically lowest common denominator across the board.
[04:22] <spm> sweet
[04:22] <lifeless> only thing likely to cause any issue is symlinks, which are different on different OS's.
[04:22] <lifeless> but we don't use them internally, its only if the project has one
[04:22] <spm> nod
[04:24] <Vornicus> And since my project already needs to deploy on several devices and I'm building it on the flash drive, I don't think that issue will arise.
[09:13] <bialix> hello bzr
[09:27]  * fullermd waves at bialix.
[09:36] <bialix> heya fullermd !~
[10:46] <jjann> Hey. Is there a way to easily restore some (deleted) files/directories from an older revision using the gui? I tried bzr qbrowse, which is very nice to browse the older revision but I'm a bit stumped that on right-click on a folder I don't get anything like "restore"
[10:50] <jjann> also, waht's the easiest/best way to query for something like "what is the latest revision that still had path/to/file?"?
[10:51] <jelmer> hi jjann
[10:52] <jelmer> jjann: I generally just use "bzr log | less" and then search for the filename.
[10:54] <jjann> I need log -v for the filenames to be shown but ok, using the pager's search feature is quite alright, thanks
[10:55] <jjann> although, I also have the use case of "what's the last revision in which $file still contained $some_string?"
[10:55] <jjann> mercurial had 'hg grep' for that
[10:58] <jjann> (I don't want to play the "hg is better" card, I wouldn't have switched if I thought that, just mentioned it to maybe help others understand what kind of functionality I'm looking for)
[11:00] <LeoNerd> I believe you can just   bzr log [filename]  can you not..?
[11:03] <jjann> LeoNerd: that doesn't help as it doesn't print the contents of the files, even with -v (also, $file might not exactly been known, sometimes I used hg grep for cases like "there has been some function called 'foo' at some point in some file, I want it back now")
[11:03] <LeoNerd> Oh... if you want the contents of the file you can  bzr cat   it
[11:03] <LeoNerd> bzr cat -r123 path/to/file  >path/to/file
[11:03] <jjann> well, then I'd need to know the revision to cat.. :)
[11:03] <LeoNerd> Which is what  log   would have given you
[11:03] <jjann> as I said, I want to find the latest revision that still contained the string 'foo'
[11:04] <LeoNerd> Ahh
[11:04] <LeoNerd> Could you somehow bisect it?
[11:04] <jjann> sure, I could script that using cat and for loop
[11:04] <LeoNerd> bzr bisect   I mean
[11:05] <jjann> but I was really hoping for something nice, I mean, isn't using a VCS for restoring old content kind of a major use case?
[11:05] <LeoNerd> Oh indeed...
[11:05] <jjann> where are all the tools to support that? ;)
[11:06] <LeoNerd> *shrug* Where's the tool to find the last revision where a prime number of files all contained a square number of lines in them? I suspect in practice relatively few people have ever had to ask such a question
[11:06] <bialix> jjann: grep plugin may help you, IMO
[11:06] <jjann> well, my case is quite a bit more general than that
[11:06] <jjann> bialix: if it does something like hg grep, it will be perfect, I'll look it up. thanks
[11:07] <bialix> grep plugin searching in the history
[11:07] <jjann> should have looked for a plugin to begin with, still not used to so much functionality being in plugins coming from other systems
[11:07] <bialix> jjann: https://launchpad.net/bzr-grep
[11:07] <jjann> yep, it pretty much exactly does what hg grep does. yay. :)
[11:07] <LeoNerd> bzr is very plugin-friendly... A lot of plugin devs write lots of interesting tools
[11:12] <jjann> LeoNerd: yeah, that I'm used to from mercurial. the difference with bzr is that quite a few things that are builtin with most other systems I've used are plugins too, just takes some getting used to as I have to start looking for plugins earlier instead of spending too much time searching for the functionality I want in bzr core
[11:13] <LeoNerd> I tend to view it differently... Don't look at it as useful core + random addons... It's more a case of "here's a universe of all the possible things, but here is a small bootstrapping core of essentials; feel free to expand it"
[11:18] <bialix> jjann: bzr core already has many many features
[11:23] <jjann> quit being so deffensive, I already like bzr. :)  It is just a difference, no judgement. bzr does have fewer features in its basic distribution than other systems. it's not even hard to argue that this is an advantage as then all these features can be developed and released independently. :)
[11:23] <jjann> I was simply noting that I didn't think to look for grep as a plugin as I'm not that used to that difference :)
[12:41] <jave> hello
[12:45] <jave> I'm using the bzr plugin with hudson to build emacs, and I'm finding it fairly flaky
[12:46] <jave> how can I reduce the bzr issues I get?
[12:46] <jave> I get "locked" issues
[12:57] <jelmer> jave: Hi
[12:57] <jelmer> jave: Can you be more specific about the errors?
[13:01] <jave> here is one type of error
[13:01] <jave> bzr: ERROR: Could not acquire lock "LockDir(file:///var/lib/hudson/jobs/emacs-trunk/workspace/.bzr/branch/lock)":
[13:01] <jave>  
[13:01] <jave> the problem is that it happens randomly.
[13:02] <jave> can you suggest some workaround so I at least get consistent builds?
[13:02] <jave> can I just remove the "held" file in the lock dir?
[13:04] <jave> heres another type of error:
[13:04] <jave> ,----
[13:04] <jave> | Started by user hudson
[13:04] <jave> | $ bzr revision-info -d /var/lib/hudson/jobs/emacs-trunk/workspace
[13:04] <jave> | [workspace] $ bzr pull --overwrite http://bzr.savannah.gnu.org/r/emacs/trunk
[13:05] <jave> | http://bzr.savannah.gnu.org/r/emacs/trunk is permanently redirected to http://bzr.savannah.gnu.org/r/emacs/trunk/
[13:05] <jave> | We expected 214886 entries, but created 214885
[13:05] <jave> | ERROR: Failed to pull
[13:05] <jave> | Getting local revision...
[13:05] <jave> | $ bzr revision-info -d /var/lib/hudson/jobs/emacs-trunk/workspace
[13:05] <jave> | null
[13:05] <jave> | Finished: FAILURE
[13:05] <jave> `----
[13:05] <jave>  
[13:05]  * Toksyuryel bops jave over the head with pastebin
[13:05] <jave> oops
[13:05] <jave> sorry
[13:08] <jave> heres the pastebin link then, for completeness
[13:08] <jave> http://emacs.pastebin.com/cBZv4HwC
[13:17] <gerard_> http://vi.pastebin.com/qmuT2CXD ;)
[13:22] <jelmer> jave: You have two instances of bzr trying to access the same branch at once
[13:23] <jave> not according to ps
[13:23] <jelmer> jam might be able to look more closely into the issue when he joins
[13:24] <jave> just to cliarify, I'm trying to set up a hudson buildserver for emacs, and I want the bzr polling and building to be very reliable
[13:25] <jave> I can of course to occasional cleanup operations, but I rather wouldnt
[13:31] <jelmer> jave: Of course
[15:50] <domas> can I import another bzr branch as a subdirectory to my "umbrella" bzr branch?
[15:52] <domas> hmm, bzr merge-into?
[15:58] <rubbs> domas: I'm assuming you're looking for something similar to svn-externals?
[15:59] <rubbs> you should lookinto bzr colocated branches and possibly bzr-scm
[15:59] <rubbs> I'll see if I can dig up links for you
[15:59] <domas> was looking something like merge-into
[15:59] <domas> this is one-time action
[15:59] <rubbs> oh, I c
[16:01] <rubbs> so, just to clarify, you have a branch and you want to import another branch in as a subdirectory within the first branch. Am I understanding this right?
[16:01] <domas> yes
[16:01] <rubbs> do you still want them to have separate histories? or just to merge the histories once and continue on as one project?
[16:02] <domas> merge histories once and continue as one project
[16:02] <rubbs> k. let me think a little on that. I'm sure it's possible, I just haven't done it yet.
[16:02] <seanh> I've heard bzr has a nice diff utility. Is it possible to use it to diff two files? (not in a bzr repository) If so, where can I find the command?
[16:06] <rubbs> domas: I'm not sure if there is an easier way, but you could in the "subdirectory" branch, create a directory under the root with the name you want the subdir to be and then move all the files in that subdir. Then commit, and then try to merge the two projects together. If I'm understanding this correct, you would then merge in the "new" folder into the umbrella branch.
[16:06] <rubbs> if any of that doesn't work you can use uncommit
[16:06] <rubbs> seanh: I'm not sure, but bzr help diff says something about --using
[16:07] <domas> rubbs: I just lost histories, nobody cares about them
[16:07] <rubbs> I've got a meeting, but I'll be back in a bit. someone else may be able to help too.
[16:07] <domas> :)
[16:07] <rubbs> domas: oh, ok
[16:07] <domas> it wasn't that important to preserve them
[16:07] <domas> only me worked on that sub-project yet :)
[16:07] <domas> thanks for assistance though!
[16:08] <seanh> Apparently something to do with python bzrlib/patiencediff.py, but I can't find patiencediff.py on my system. Might have to checkout the bzr source
[16:08] <seanh> Hmm, no, bzr is installed, I just don't know how to find the damn file
[16:09] <mgz> seanh: `python -m bzrlib.patiencediff -h` ?
[16:11] <seanh> Yes! Thanks mgz
[16:11] <seanh> diff was giving completely f*cking useless output on some simple config files and making life suck, this works!
[16:48] <GaryvdM> Hi all!
[16:49] <GaryvdM> jam: Please could you turn on the ec2 machine. I would like to another build.
[16:51] <jam> GaryvdM: spinning it up now. probably takes ~10min to start
[16:51] <GaryvdM> jam: Ok thanks.
[16:51]  * jelmer waves to GaryvdM, jam
[16:52] <jam> morning jelmer
[16:53] <GaryvdM> Hi jelmer
[16:57] <mgz> jelmer: quick question re 587074
[16:57] <mgz> +bug
[16:57] <jelmer> hi mgz
[16:57] <jelmer> bug 587074 ?
[16:57] <mgz> I take it rev 984 only fixes the utf-8 case?
[16:57] <jelmer> mgz: sure, what about it?
[16:58] <mgz> as you don't seem to have touched the other path.
[16:58] <mgz> do you want a child bug spun up on the other issue with nix any-bytes-will-do repos?
[16:58] <jelmer> mgz: I'm not sure I follow. what do you mean by the other issue?
[16:58] <jelmer> mgz: supporting non-utf8 characters in paths imported from git?
[16:59] <mgz> well, what happens if .decode("utf8") fails. yeah.
[16:59] <jelmer> mgz: If you have suggestions as to how we should handle that...
[17:00] <mgz> well, a nice error explaining the problem might be step one :) (but yup, a sensible end solution is not easy to devise)
[17:02] <jelmer> we have no way of knowing the encoding for sure, and since we need to have a deterministic way of handling these situations, I think we should not support non-utf8 paths at all.
[17:02] <jelmer> Having a better error message would be nice, indeed. Bug reports and patches welcome :-)
[17:05] <mgz> okay, I'll spin one off.
[17:07] <jam> jelmer: .decode('utf-8').decode('latin-1') is a fairly common solution, as long as it is done consistently
[17:07] <jam> but yeah, avoiding the temptation to guess for now is probably reasonable
[17:09] <jelmer> jam: The problem with falling back to latin-1 is that I need to have a way of reconstructing the original bytestring
[17:09] <jam> ah
[17:12] <mgz> 's similar to problems with checking out bzr repos onto filesystems with smaller idea of what a valid name is
[17:13] <mgz> need some kind of rename, but not mess up the repo for everyone else when pushing
[17:38] <GaryvdM> jam: We need to upgrade paramiko, as version we are currently packaging gives off hashlib DeprecationWarnings. I'm going to try make the scripts pull a set verison using buildout, rather than us the installed version.
[17:38] <jam> GaryvdM: is there a properly fixed version of paramiko?
[17:38] <jam> The other option is to hack pycrypto, which we've done in the past
[17:39] <jam> I agree using a script version would be nice, I don't think it is easy to do.
[17:39] <GaryvdM> jam: Oh - I just assumed there is a fixed version. I'll check...
[17:41] <mgz> seems like there's no release since 2009
[17:41] <mgz> there's also http://www.lag.net/pipermail/paramiko/2010-May/001303.html
[17:41] <mgz> did andrew do a ppa or something?
[17:42] <GaryvdM> I'm busy looking at the ubuntu package to see if it is patched..
[17:48] <GaryvdM> I'm confused now. How dose pycrypto relate to paramiko? alternates, or is the one dependent on the other.
[17:50] <GaryvdM> ah - paramiko depends on pycrypto...
[18:46] <jam> GaryvdM: right, paramiko uses pycrypto to do all of the actual encryption-on-the-wire
[18:48] <GaryvdM> jam: Right. I was going to ask you where the patch version is, but It's better if I do a clean room patch so that I can submit it.
[18:48] <GaryvdM> http://www.dlitz.net/software/pycrypto/submission-requirements/
[18:49] <jam> GaryvdM: well, I think you actually need to patch paramiko if you want something that you can submit
[18:49] <GaryvdM> They only accept non US submissions
[18:49] <jam> pycrypto chose to deprecate (verbosely) an old api
[18:49] <jam> I believe there is a new one you can use
[18:49] <GaryvdM> Oh - ok..
[18:49] <jam> robey hasn't seemed very interested in maintaining paramiko, though I'll also note it switched hosting to git+github
[18:50] <jam> http://github.com/robey/paramiko
[18:50] <jam> shows that there is *some* activity, not sure why there isn't a new release which is compatible with the new pycrypto
[18:51] <jam> there was a bit of a chicken-and-egg since we couldn't have paramiko use the new functionality, until pycrypto released it
[18:51] <jam> and then the question is, does paramiko then *require* the new pycrypto
[19:17] <Larsigoreng> Hi, is ther somebody online able to help me with a (hopefully) simple question? I want to go back in history to version 1 of my files, but I am lost in the meanings of all the words revert, uncommit etc.
[19:18] <GaryvdM> Larsigoreng: Do you want to commit the old version into the history permantly, to just go back to the old version temporaly?
[19:18] <Larsigoreng> anyone alive in here? :)
[19:20] <Larsigoreng> Hi GaryvdM! I have old versions of configuration files. I changed these files, committed them...
[19:20] <Larsigoreng> and fpound out that these changes are no good. So I want to revert that
[19:21] <GaryvdM> bla - sorry Larsigoreng. I press ctrl q by mistake
[19:21] <Larsigoreng> and fpound out that these changes are no good. So I want to revert these changes and this committing
[19:21] <Larsigoreng> no prob. You got my story?
[19:21] <GaryvdM> Larsigoreng: yes
[19:22] <GaryvdM> Larsigoreng: Is this in the last revision, or a couple of revisions back?
[19:22] <Larsigoreng> So, to be honest, I don't understand your question in the necessary details.
[19:22] <Larsigoreng> there is revision 2 with the new versions
[19:22] <Larsigoreng> and revision 1 with the old versions
[19:22] <Larsigoreng> I want revision 1 to reappear
[19:23] <GaryvdM> Larsigoreng: The easy answer is to do a revert + commit
[19:23] <GaryvdM> and the safest...
[19:23] <Larsigoreng> bzr revert -r 2    ; bzr commit   ?
[19:23] <GaryvdM> yes
[19:24] <GaryvdM> or bzr revert FILE -r 2
[19:24] <Larsigoreng> there is not yet a change before I do the bzr commit?
[19:25] <Larsigoreng> ´cos I did the revert already, but np commit
[19:25] <GaryvdM> Larsigoreng: There should be
[19:25] <GaryvdM> oh .. wait
[19:25] <GaryvdM> Larsigoreng: bzr revert -r 1
[19:25] <GaryvdM> -r 2 = the current version
[19:25] <GaryvdM> you want to go back to -r 1
[19:26] <Larsigoreng> okay! So -r 1 is the target-version?
[19:26] <GaryvdM> Larsigoreng: Yes
[19:26] <Larsigoreng> (and not the version I want to revert) Oh then I misunderstood the manual! Let me try!
[19:28] <Larsigoreng> okay, that looks good. So I reverted it back to version one, and when I committed it, it says this is now version 3.
[19:28] <Larsigoreng> version = revision
[19:29]  * Larsigoreng has to do a lot of learning...
[19:30] <GaryvdM> Larsigoreng: So you build a better understanding: revert + commit will show in the history (which may or may not be a good thing.)
[19:31] <Larsigoreng> *puh* thank you very much, GaryvdM
[19:31] <GaryvdM> Larsigoreng: uncommit + revert won't show in the history, but will cause problems  for any body else who has a copy, so only use uncommit if you have not pushed.
[19:31] <Larsigoreng> "will show in the history" = is logged and anyone interested in that can find out about that?
[19:31] <GaryvdM> Larsigoreng: Yes
[19:31] <GaryvdM> Larsigoreng: run bzr log to see
[19:35] <Larsigoreng> GaryvdM: sorry, I accidentally pressed CTRL+W... ;)
[19:36] <jam> jelmer: meliae-0.3.0 is released with a tag and a tarball uploaded, can you package it?
[19:36] <jelmer> 0.3.0 \o/
[19:36] <Larsigoreng> GaryvdM: Thank you very much, you saved my evening!
[19:36] <GaryvdM> Larsigoreng: Glad I could help :-)
[19:36] <jelmer> jam: sure
[19:36]  * Larsigoreng waves goodbye.
[19:42] <GaryvdM> jam: How are you using meliae to debug gcc if gcc is in c?
[19:50] <jelmer> GaryvdM: I think he means the gcc branch :-)
[19:50] <GaryvdM> Oh - I see...
[19:50] <GaryvdM> lol
[19:52] <GaryvdM> Hmm - having to use git. I'm finding gitk a bit lacking.
[19:54] <GaryvdM> Maybe it's just because I expect gui's to behave ..
[19:54]  * GaryvdM must not be prejudice...
[20:07] <GaryvdM> jam: We are packaging pycrypto 2.0.1, and 2.1.0 is out, which claims to add python 2.6 support. May I install 2.1.0
[20:08] <jam> GaryvdM: 2.1.0 adds different deprecation warnings, but you can use it if you want
[20:08] <jam> 2.0.1 gives the hashlib warnings
[20:08] <jam> 2.1.0 gives paramiko RandPool warnings
[20:08] <GaryvdM> Ok - I see :-(
[20:09] <jam> *1* of the reasons we stayed with 2.5 for so long
[20:10] <GaryvdM> Do you think I will be a lot of work for me to patch paramiko?
[20:11] <jam> GaryvdM: I don't *think* it would be a huge amount, but it is enough that nobody has done it yet...
[20:11] <jam> I don't know why robey hasn't updated, for example
[20:12]  * GaryvdM dives in...
[20:13] <GaryvdM> jam: Please will you shut down the ec2 machine. I'm done for now.
[20:13] <jam> k
[20:13] <jam> will do
[20:13] <jam> GaryvdM: if you are going to use it, say, tomorrow, I'll leave it for you
[20:13] <jam> but if you are done for a while, I'll shut it down
[20:14] <jam> (especially given the TZ differences and my desire to be asleep when you wake up :)
[20:14] <GaryvdM> jam: I work on bzr in the same tz as you (after work)
[20:15] <GaryvdM> jam: Expect last week when I was on leave
[20:15] <jam> up to you. It is nice to shut it down, but I know it adds a fair amount of startup overhead for you to get your stuff done
[20:15] <GaryvdM> jam: I'll want to do a release when I have a paramiko/pycrypto solution, or when the next release comes out...
[20:16] <GaryvdM> s/release/installer build
[20:16] <jam> sure. probably later this week. I think it was actually targetted for the end of last week.
[20:19] <jelmer> jam: Any chance I could get you to take a brief look at lp:~jelmer/bzr/controldir, to check if what I'm doing is vaguely reasonable ?
[20:19] <GaryvdM> jam: deadline is 12 Aug. Maverick feature freeze...
[20:19] <GaryvdM> Next week Thursday.
[20:25] <jelmer> jam: (in-progress MP here: https://code.edge.launchpad.net/~jelmer/bzr/controldir/+merge/31573)
[20:25] <jam> jelmer: I think you accidentally submitted this for review 2x, or maybe you just directly requested my review?
[20:26] <jelmer> jam: I submitted it for review earlier as well but removed that MP
[20:26] <jam> jelmer: ah, different numbers, but 2 emails about review, anyway looking
[20:27] <jelmer> jam: Thanks. I'm basically splitting ControlDirFormat and "Prober" out of BzrDirFormat
[20:30] <jam> jelmer: changing bzrdir.sprout is going to break a *lot* of tests
[20:30] <jelmer> jam: I haven't changed it, just moved it to the new base class of BzrDir.
[20:38] <jam> jelmer: it seems ok, but at this point it is just moving code around, so I'd have to understand your rationale of why you want it moved
[20:38] <jelmer> jam: Mainly I'm looking at running some of the tests that currently live in per_bzrdir only against BzrDir instances and not against other ControlDir instances.
[20:39] <jelmer> jam: The reason for splitting out Prober is so that we can add more advanced probing mechanisms later. SvnProber would never need to recurse down - if the current directory doesn't have a .svn/ control directory then the parent won't either. Or we can do probing based on the reply of the OPTIONS HTTP request, etc.
[20:40] <jelmer> jam: And in general just cleaning up the distinction between the API and Bazaar-specific stuff.
[20:50] <jam> GaryvdM: I submitted your bzrw patch
[20:51] <GaryvdM> jam: Thanks
[20:51] <jam> GaryvdM: however, i get a text conflict in NEWS
[20:51] <GaryvdM> jam: I'll fix.
[20:56] <jam> jelmer: I like the concept of splitting things up a bit. BzrDir is a rather large interface ATM.
[20:57] <GaryvdM> jam: Done.
[20:58] <jam> GaryvdM: submitted
[20:59] <GaryvdM> Thanks.
[21:12] <jelmer> jam: So, did you manage to find the issue with lp:gcc?
[21:18] <jam> jelmer: it is a few issues, the original post is sort of long
[21:18] <jam> but basically, 150+MB is from loading the whole chk index (.cix)
[21:19] <jam> and then about as much memory is in the actual chk maps themselves
[21:19] <jam> and about 50M in the dirstate
[21:19] <jam> some of that we can shrink easily, some not very easily at all
[21:21] <jam> cix stuff...
[21:21] <jam> the gcc-linaro code is large enough to cover 50k chk pages
[21:21] <jam> because .cix is content addressed, the sha hashes spread that evenly over the whole index
[21:21] <jam> so while there are >700k entries, we fit 100 per block, so there are only 7k blocks
[21:22] <jam> so to read 50k evenly spaced we have to read *all* 7k
[21:22] <jam> I don't have great answers here other than a) custom data structure that is more compact, b) new index for .cix (which I've described some possibilities before)
[21:22] <jam> but that is a disk-format change
[23:13] <cwr> hi
[23:13] <jelmer> hi
[23:16] <cwr> I'am trying to pull new revisions from a repo hosted on sf.net to my laptop. unfortunately i get this error message
[23:16] <cwr> http://pastebin.org/442651
[23:16] <cwr> am i doing something wrong?
[23:17] <jelmer> are you trying to pull into a branch that is bound to another (readonly) branch perhaps?
[23:22] <cwr> hmm, not so sure about that. it is bound to a different branch, yes. I used a second branch to commit experimental changes and want to pull them on my laptop now
[23:24] <jelmer> cwr: In that case, you should unbind the branch first
[23:24] <jelmer> cwr: it wants to keep the remote ("master") branch up to date but is failing when trying to put the revisions you're pulling in there.
[23:26] <cwr> ok, did what you said and it is working. nice thank you!!
[23:27] <jelmer> lifeless: Hi
[23:27] <lifeless> hi
[23:28] <GaryvdM> jam: Patched paramiko: http://github.com/garyvdm/paramiko
[23:28] <jelmer> lifeless: Thanks for having a look at my controldir branch. To answer your question, the only reason I didn't use ControlComponent as baseclass for ControlDir was that not all ControlDirs would have a ControlTransport that is accessible.
[23:28] <GaryvdM> I'm off to bed now.
[23:29] <lifeless> jelmer: so, the contract that Martin introduced with ControlTransport is that they will have.
[23:29] <lifeless> jelmer: or many bzr commands will go boom, AIUI.
[23:29] <jelmer> lifeless: what about e.g. git branches that are basically files on disk or an entry in a dictionary?
[23:30] <jelmer> poolie: Hi
[23:31] <jelmer> Perhaps control_url and user_url can be mandatory but control_transport and user_transport optional?
[23:31] <lifeless> jelmer: they still have a conceptual url (;branch=xxx), and where there is a url there is a transport
[23:32] <lifeless> jelmer: but, controldir is the .git dir, not the branch object *anyway* so that seems an unrelated question
[23:33] <jelmer> lifeless: A similar argument applies to e.g. remote git servers though
[23:33] <lifeless> jelmer: it seems pretty weak; git: transports can in principle exist
[23:33] <jelmer> lifeless: In that case we have only one transport that basically only provides a method for getting a Git smart server client.
[23:34] <lifeless> jelmer: a command that prints branch.bzrdir.user_transport, should still do something sensible there.
[23:34] <lifeless> no?
[23:34] <jelmer> lifeless: I don't particularly see why it needs user_transport rather than user_url.
[23:36] <jelmer> I can of course provide two dummy stubs for Git that just implement Transport.base, but I'd like to understand why that extra code is necessary.
[23:36] <lifeless> jelmer: consistency of interface is the argument I'd use
[23:36] <lifeless> or rather
[23:36] <lifeless> controltransport is meant to be a base for all these things.
[23:37] <lifeless> please either refine it appropriately, or meet the contract - I don't have an opinion as to which is better.
[23:37] <jelmer> lifeless: s/ControlTransport/ControlComponent/ ?
[23:37] <lifeless> *I* consider transport == url in all regards
[23:37] <jelmer> ControlComponent has both control_transport/user_transport and control_url/user_url properties
[23:37] <lifeless> so if I was doing the work, I would probably drop the _url attributes and use the transport ones only, but thats me.
[23:38] <jelmer> poolie: ping
[23:38] <poolie> jelmer: hi! i'm on the phone at the moment
[23:40] <jelmer> poolie: Ah, ok
[23:41] <jelmer> lifeless: Anyway, you make a good point. I'll derive ControlDir from ControlComponent.
[23:41] <lifeless> jelmer: thanks!
[23:44] <maxb> Is anyone else experiencing lp:bzr/2.2 not clearing its progress displays from the terminal properly?