[00:03] <spiv> Peng: you can use branches to do the same thing as looms, but it's a lot more convenient with looms.
[00:03] <Peng> Okay.
[00:05] <spiv> igc: https://bugs.edge.launchpad.net/bzr/+bug/230550
[01:04] <igc> bbiab
[03:11]  * igc lunch
[04:17] <lifeless> hey guyes
[04:18] <lifeless> spiv: ah good, you found the bug report :)
[04:22] <igc> hi lifeless
[04:33] <spiv> lifeless: yep :)
[05:34] <lifeless> spiv:  -> food, but happy to discuss later if you need to chat about it
[05:40]  * igc pick up kids - bbian
[06:13] <lifeless> spiv: back; so how is that bug going ?
[06:15] <spiv> lifeless: _SmartClient._base is getting out of sync with _SmartClient._medium's URL
[06:15] <spiv> lifeless: so it appears that the client/medium sharing logic in RemoteBzrDir isn't quite right.
[06:15] <lifeless> spiv: excelennt; that was my suspicion :)
[08:01] <vila> lifeless: http://paste.ubuntu.com/13090/
[08:01] <vila> Note that the http benchmark spend 212 seconds waiting for a 502 Bad gateway. So subtract that.
[08:02] <vila> After the substraction I can't see huge differences so I'm wondering about wether there is such a discrepancy between sftp and http.
[08:03] <uniscript> how do I bzr ignore .svn directories?
[08:03] <vila> In other words, either the kenisson (sp?) experiment was flawed or I need better info on how to reproduce it.
[08:03] <bob2_> "bzr ignore .svn" doesn't cut it?
[08:04] <uniscript> I get errors with the bzr-svn plugin
[08:04] <uniscript> with bzr add .
[08:04] <uniscript> tries to do a PROPFIND
[08:05] <uniscript>  bzr add --dry-run -v .
[08:05] <uniscript> bzr: ERROR: libsvn._core.SubversionException: ("PROPFIND request failed on '/svn/repos/keith/DocCharConvert/trunk/DocCharConvert'", 175002)
[08:05] <spiv> vila: you mean Kinnison?
[08:06] <vila> spiv: yeah! Thanks. Thanks for your review and invalidating my bug report too ;-)
[08:06] <vila> Kinnison: apologies for the typo, I need another coffee :)
[08:08] <spiv> vila: You're welcome :)
[08:08] <spiv> vila: that's the easy part compared to actually fixing a bug :)
[08:09] <spiv> vila: I had a quick look at it when it was reported and couldn't see what was needed, but you made the solution look pretty easy.
[08:11] <vila> spiv: yeah, I had a wtf moment when realizing that _post wasn't calling _raise_curl_http_error and then another when I realized that _post wasn't using accepted_errors, that made the bug quite subtle
[08:11] <vila> but overall, I'm gulty of not working more on the hpss ;-)
[08:13] <spiv> If _post isn't reusing stuff that it should, then it would be great to fix that :)
[08:14] <poolie> i'm going to do a couple of reviews of ian's work then call it a day
[08:16] <vila> spiv: now that I can write tests, I may as well refactor _post, I think we shouldn't annex _post just for the smart server when we already have send_http_smart_request...
[08:16] <spiv> vila: that sounds good.
[08:16] <vila> ... even if that means having two send_http_smart_request implementations ;-)
[08:17] <spiv> vila: although I'd be tempted to land a short-term fix first, before embarking on a bigger change
[08:17] <spiv> Depends on how quickly you can do the proper fix :)
[08:19] <gour> is anyone using fish shell? (there is no tab-completion for bzr :-(
[08:21] <lifeless> vila: is your http cached perhaps ?
[08:21] <lifeless> vila: kinnison is usually quite good ;P
[08:22] <vila> lifeless: no cache here, never, pipe is big enough (which explains why I'm so bad at undersanding squid issues and high latencies problems ;)
[08:23] <gour> hmm, it looks that bash-completion is also not up to date :-/
[08:24] <vila> lifeless: I don't doubt Kinnison, it's just that I can't reproduce ;-)
[08:25] <vila> Kinnison: when you come back, let's discuss a bit, I'd be interested in some stats via the transportstats plugin
[08:25] <visik7> I'm new to vcs, I would using it to fork my project to have 2 version: one for experimental purpose the other for production
[08:27] <visik7> but before this I've some questions:
[08:27] <visik7> 1st: I've a so called "projects" folder
[08:28] <visik7> is more logical to put the dir under a unique bzr branch or to create a bzr branch for each project ?
[08:28] <Peng> The latter.
[08:30] <visik7> 2nd: how can I fork my project ? should I use the switch command ?
[08:32] <poolie> visik7: use 'bzr branch production experimental'
[08:32] <poolie> well
[08:32] <poolie> first put your code in a directory called eg 'production'
[08:32] <poolie> then that will create another copy of it called experimental
[08:33] <visik7> and when I need to merge some or all the code from experimantal to production ?
[08:35] <jamesh> visik7: the workflow I usually use is to develop features on their own branches
[08:35] <jamesh> this makes it easy to merge them on their own
[08:38] <visik7> jamesh: so no split the code into 2 dirs ? becouse I would to continue to develop on devel and production as well
[08:38] <visik7> maybe I've not understand your workflow
[08:39] <visik7> :(
[08:43] <bob2_> merging only part of one branch into another is a bit problematic (in bzr at the moment)
[08:57] <Kinnison> vila: hi, bug me when you're around and we can discuss
[09:00] <igc> night all
[09:00] <vila> Kinnison: installing stuff on a windows machine in parallel, let's discuss
[09:01] <Kinnison> okies
[09:01] <Kinnison> So what are you after me for?
[09:02] <vila> lifeless told me you were observing different behaviors between sftp and http regarding bandwidth usage. I can reproduce it. Can you tell me more about your experiment ?
[09:02] <vila> grr, s/can reproduce/can't reproduce/
[09:03] <spiv> vila: I make that typo lots too.
[09:04] <vila> broadcast: read my mind while I'm using windows
[09:08] <Kinnison> vila: sure, let me prep, I've reinstalled my PC since then.
[09:09] <vila> ok
[09:09] <Kinnison> Okay, so here's the deal, when I did the test, I was branching bzr.dev over my 'net connection which is a 10Mbit cable service from my Colo box which has plenty of bandwidth and reasonable enough CPU etc.
[09:11] <Kinnison> Now, this is plain http (I.E. not smart) and it seemed to take around twice (wallclock) that of sftp
[09:12] <Kinnison> I have an http_proxy set, which is on my local network to my seriously overpowered core server which runs a reasonably well configured squid
[09:12] <Kinnison> Now when it's fetching the packs, the HTTP fill the 1.2MB/s
[09:13] <Kinnison> But once it's on to the smaller files, it slows down dramatically
[09:14] <Kinnison> As though it's not pipelining or something
[09:14] <spiv> Kinnison: (btw, I've seen the opposite effect: a bug in the way some versions of squid handle "Range: 0-..." request causing fetching of data from packs to be extremely slow)
[09:14] <Kinnison> This is an initial branch
[09:15] <Kinnison> so presumably it fetches the whole pack, no?
[09:15] <spiv> Depends on the pack.
[09:15] <Kinnison> oh
[09:15] <spiv> e.g. if it's shared repo
[09:15] <Kinnison> standalone branch
[09:15] <spiv> There will almost certainly be revisions in there you don't need, so bzr won't fetch the whole pack.
[09:16]  * Kinnison runs the branch again to re-time
[09:16] <visik7> bob2_: are other vcs less problematic with this kind of usage ?
[09:16] <Kinnison> since last one got moosed by presence of updatedb
[09:17] <vila> Kinnison: Wait ! Can you do that with the transportstats plugin installed and prefix your urls with 'stats+' ?
[09:17] <Kinnison> where do I get that plugin?
[09:17] <vila> as I did in http://paste.ubuntu.com/13090/
[09:18] <vila> bzr branch lp:~vila/bzr/transportstats
[09:20] <bob2_> visik7: I'm not sure.  jamesh was suggesting that you develop each feature in different branch, then you can choose which whole branch to merge into production or experimental
[09:21] <visik7> bob2_: I think that will drive me crazy 'couse I would use this as a one man developer tool
[09:21] <visik7> :)
[09:21] <Kinnison> vila: running the http branch now
[09:23] <vila> Kinnison: You said "seemed to take around twice (wallclock)", so we may not be dealing with bandwidth problems here...
[09:25] <vila> Regarding  the transportstats plugin, it creates a '.transport_stats_for_bzr' file cumulating the operations measured, so let's try to be clean about how we use it, i.e. run your operations in different directories as much as possible
[09:29] <vila> .. or alternatively and surely easier for you rename the file between each operation when necessary
[09:29] <Kinnison> okay, how do I get the stats for this op?
[09:30] <visik7> ops
[09:34] <poolie> night
[09:38] <vila> Kinnison: bzr ts-display
[09:39] <sabdfl> visik7: it's actually nice to work on features separately
[09:39] <sabdfl> you can merge them if two features become interdependent
[09:42] <visik7> sabdfl: someone point me to hg queues
[09:42] <Kinnison> vila: http://rafb.net/p/D4vKEA23.html
[09:43] <Kinnison> vila: woah, that's huge latency
[09:43]  * Kinnison tries the same op again, without the http proxy
[09:43] <Kinnison> For reference, that took 4:29.06 wallclock to branch bzr.dev
[09:43] <sabdfl> visik7: i think you'll find independent branches better, it's easier to keep track of the thread of development of each feature
[09:43] <sabdfl> but, try everything
[09:44] <vila> Kinnison: Beware! It's not your usual latency, that's the "real" latency as measured between when we send a request and when we receive the response, not to be confused with ping
[09:44] <visik7> sabdfl: and on #git they told me that "you can cherry-pick every commit you want from one branch to another"
[09:44] <Kinnison> vila: indeed, hence it seems huge
[09:44] <Kinnison> considering my average ping time is 15ms
[09:44] <vila> ouch, yes, that's huge
[09:45]  * Kinnison tries without squid now
[09:45] <visik7> sabdfl: I wouldn't to start with a vcs to realize that don't do what I look for
[09:45] <vila> you can try 'bzr ts-display -v' but be prepared to receive a huge output
[09:47] <sabdfl> visik7: i'm sure every tool has a way to achieve your goal
[09:47] <vila> Kinnison: do you know if you use the pycurl or the urllib based implementation  ?
[09:47] <sabdfl> my recommendation would be to setup a share repo, with branches in directories under that
[09:47] <Kinnison> I haven't a clue, this is a fresh hardy install, with bzr.dev
[09:47] <sabdfl> have a trunk branch, then branches for each of the features you are working on
[09:47] <sabdfl> you can merge the features into trunk when they are ready
[09:47] <sabdfl> works really well for me
[09:47] <vila> try 'import pycurl', if it's there it's used
[09:47] <Kinnison> vila: right, without squid in the way, it takes 2:24 wallclock with an average latency of 420ms
[09:48] <visik7> sabdfl: thanks for the advice
[09:48] <sabdfl> sure
[09:49] <Kinnison> vila: not present
[09:49] <vila> hmmm, squid playing tricks again :-/ Yet 420 seems still huge, let me check from here (you branched from lp:bzr ?)
[09:49] <Kinnison> No, from my server
[09:49] <vila> Kinnison: good, so you're using the urllib based one
[09:49] <Kinnison> since I can monitor that and be sure it's not overloaded when I do the trials
[09:49] <Kinnison> :-)
[09:49] <vila> Kinnison: apache ?
[09:50] <Kinnison> Zeus
[09:50] <Kinnison> (very high performance web server)
[09:50] <vila> Kinnison: I don't know that one :-/
[09:51] <Kinnison> SFTP is 1:53.21 wallclock with 107ms average latency
[09:51] <vila> let start again then, let's forget stats, there is chances that Zeus does not handle range requests as we want, try 'bzr branch -Dhttp' and mail me the relevant .log
[09:52] <Kinnison> where does the .log end up?
[09:52] <vila> sftp/ 1.53, http/2.24, that's more reasonable
[09:52] <vila> bzr version will tell you, but on linux it's ~/.bzr.log
[09:52] <Kinnison> I'll clear that down first then
[09:52] <vila> you can delete it before
[09:52] <vila> z:)
[09:52] <vila> Kinnison: perfect
[09:53] <Kinnison> branching -Dhttp now
[09:53] <vila> great
[09:56] <uniscript> I dimly remember there is a way to disable plugins for a bzr command?
[09:57] <vila> uniscript: bzr --no-plugins
[09:57] <uniscript> ta
[10:00] <Kinnison> vila: http://www.digital-scurf.org/files/http-proxied-debug.log
[10:00] <Kinnison> vila: http://www.digital-scurf.org/files/http-direct-debug.log
[10:02] <Kinnison> vila: of use?
[10:02] <vila> Kinnison: just downloaded, let me look :)
[10:02] <Kinnison> for reference, that http-direct took 1:54.8 and the http proxied took 4:06.67
[10:08] <vila> the proxied one seems to choke on some very big range requests, triggering a retry that is accepted
[10:09] <vila> the timings appears in the log, I need more time for a more precise analysis, I'll kept you informed
[10:09] <Kinnison> Okay, be sure to prefix with my name, I'll go off to do other things and i'll come back if this window goes red :-)
[10:10] <vila> Kinnison: ok, it may not be today though, tonight at best (i.e. in ~10 hours)
[10:10] <Kinnison> Heh, okay, I'll try and spot in scrollback
[10:12] <vila> Kinnison: But one important thing already: Zeus seems to happily handle our range requests, so comparing sftp with zeus-not-proxied should be relevant in terms of relative performances *today*
[10:14] <visik7> sabdfl: I realized that maybe multibranch is a little bit complicated for the task that I want to acheeve: I have a project, I want to "fork" it and develop 2 different version, but only one feature is in the new branch, I would keep the 2 branch synced is it possible ?
[10:14] <visik7> sabdfl: sorry if I bother you
[10:20] <jml> hi
[10:20] <jml> statik: sorry about the plugin name thing.
[10:27] <mwhudson> jml: hello!
[10:27] <mwhudson> jml: how is europe?
[10:31] <jml> mwhudson: europe is wonderful and european.
[10:31] <jml> mwhudson: I wish I could spend more time here
[10:32] <mwhudson> jml: are you going to get out of the city at all?
[10:33] <jml> mwhudson: unlikely.
[10:33] <jml> mwhudson: it'll take a fair bit of effort to make sure I see the city, in fact.
[10:34] <mwhudson> jml: :/
[10:34] <mwhudson> at least prague is worth seeing
[10:34] <jml> mwhudson: *nod*
[10:34] <mwhudson> (i hear, not been there myself)
[10:34] <jml> mwhudson: it is.
[10:34] <jml> mwhudson: also, I think that the pubs here rival and perhaps best English pubs
[10:34] <mwhudson> heh
[10:35] <jml> mwhudson: oh btw, I read _Rob Roy_ on the flight over.
[10:35] <jml> I want to go to Scotland now.
[10:35] <mwhudson> i've seen his grave, i think
[10:35] <mwhudson> rob roy is wallace?
[10:36] <mwhudson> er, scott
[10:36] <jml> yes.
[10:36] <lifeless> poolie: hi; I may have come across badly in my latest email
[10:37] <lifeless> poolie: please forgive :)
[10:38] <mwhudson> jml: scotland is well worth seeing
[10:38] <ToyKeeper> visik7: You might want http://bazaar-vcs.org/Rebase
[10:38] <mwhudson> the valley containing the church where rob roy's grave is is beautiful
[10:39] <mwhudson> jml: http://www.lochsidecottages.co.uk/Image8.jpg for example
[10:42] <jml> mwhudson: yeah. indeed.
[10:42] <lifeless> visik7: all you need to do is merge from one brancht o the other on a regular bssis
[10:42] <lifeless> visik7: this sort of synchronisation is the reason bzr exists :) - its core functionality
[10:46] <ToyKeeper> visik7: bzr rebase and git-rebase and hg patch queues are all very similar...  but it's better not to use them if you don't really need to.
[10:58] <ToyKeeper> visik7: Er, the rebase features basically help you work around certain problems...  but why work around a problem when you can avoid it entirely?
[10:58] <visik7> ToyKeeper: how ?
[10:59] <ToyKeeper> If you have write access to the main branch, there is probably no need to maintain a stack of patches separate from the trunk.
[11:01] <ToyKeeper> But if upstream is read-only, and you have extensive local changes which upstream won't accept, 'rebase' features can help you keep your local patches up to date.
[11:02] <visik7> follow my reasoning: I've a project up and running, I would develop new features on a parallel brench keep syncing with the "trunk" and I need to develop new features also on trunk
[11:03] <visik7> so rebasing or merging seems the right solution isn't it?
[11:03] <ToyKeeper> In that case, regular merging should be fine.  That's what bzr is best at.
[11:03] <visik7> so I've not understood the difference between merge and rebase
[11:04] <ToyKeeper> Merging is the normal process in bzr.  You can push/pull/branch/merge freely.
[11:05] <ToyKeeper> Rebase is for pretty specific types of use.
[11:05] <ToyKeeper> For example, you get foo-1.3.tar.gz, unpack it, and make changes...  then foo-1.4.tar.gz is released.
[11:05] <ToyKeeper> 'foo' is not in bzr, but your patches are.
[11:06] <ToyKeeper> Rebase makes it easier to take your foo-1.3 patches and make them work on foo-1.4.
[11:07] <visik7> I got it
[11:10] <spiv> visik7: rebase writes a new history for a branch
[11:10] <spiv> visik7: which is detrimental to regular merging
[11:14] <visik7> thank you guys for all those infos, time to dive into bzr
[11:14] <visik7> see you soon
[11:34] <brilliantnut> spiv: I see that you have a fix for bug 230550 ... does this means it goes into 1.6?
[11:34] <spiv> brilliantnut: yes
[11:36] <brilliantnut> hmm, and is there a chance that I can try it out before?
[11:36] <brilliantnut> I have a branch off bzr.dev, if it makes a difference...
[11:40] <spiv> brilliantnut: it's a work in progress, but I just registered the branch in LP and linked it to that bug
[11:40] <spiv> brilliantnut: http://people.ubuntu.com/~andrew/bzr/bug-230550 is the URL
[13:01] <Peng> What would cause .bzr/repository/lock/foo.tmp/info to be left behind from months ago, but not be causing problems when trying to push?
[13:17] <lifeless> Peng: that is a tmp file used when obtaining/releasing a lock, not an actual lock
[13:19] <statik> jml, no apologies needed for the plugin name, thanks for writing a useful plugin!
[14:08] <dennda> Hi. I have settings.py under version control but want to ignore it from now on, without removing it (it's values change from machine to machine.) How do I do that?
[14:12] <thekorn> dennda, bzr remove --keep <yourfile>
[14:12] <thekorn> bzr ignore <yourefile>
[14:13] <thekorn> that's at least what I would do in such a case
[14:18] <dennda> thekorn: thanks :)
[16:21] <siretart> jelmer: hi. would you please commit your latest bzr_1.5-1 upload to debian to bzr.debian.org? TIA!
[16:30] <dato> siretart: are you going to upload bzr to backports?
[16:36] <siretart> dato: I have just merged bzrtools, and wanted to prepare an bzr upload, so yes
[16:37] <siretart> preparing in the sense of building and publishing it on gluck, and having it ready to be uploaded as soon as stuff transitions to testing
[16:37] <dato> ah; I've been asked a backport of 1.3.1, that's why I asked
[16:48] <demod> hi
[17:46] <lifeless> jam: ping
[17:51] <lifeless> jam: unping, have test passing remoind me sometime to discuss write_revision_to_string with you
[18:02] <vila> 1.5 has been released ? Or is it still in rc ?
[18:02] <vila> lp doesn't have 1.5 series defined (hence the question)
[18:02] <vila> lp doesn't have 1.6 series defined (hence the question)
[18:02] <vila> grr
[18:02] <beuno> vila, it's been released, yes
[18:03] <vila> 1.6 serie or 1.6 milestone, I'm unclear about the vocabulary, but I need the later for marking a bug as released
[18:04] <vila> beuno: thks
[18:05] <pickscrape> Would I be right in thinking that 1.6 is going to be quite an exciting release?
[18:05] <jam> vila: if we don't have 1.6 marked, I'll go do it
[18:06] <jam> we certainly should have a milestone for it
[18:06] <jam> and possibly a release series
[18:06] <vila> jam: thanks
[18:07] <jam> vila: we now have both a release series and a milestone for 1.6
[18:07] <vila> jam: faster than light ;-)
[18:07] <jam> In the past, a lot of milestones were based on 'trunk' rather than a specific release series, but the last few have been on the series
[18:07] <jam> so I kept it that way
[18:08] <jam> vila: it isn't too hard when you've done it several times :) It is a bit tricky when you don't know where to look
[18:08] <jam> (like that milestones aren't against the project, they are against 1 release series, etc)
[18:09] <jam> man I hate that 'series' has no plural form, and that its singular form *looks* plural
[18:09] <jam> stupid English
[18:09] <pickscrape> sheep
[18:09] <jam> vila: is it any better in French?
[18:09] <vila> is that described in the how-do-I-make-a-new-release doc ? I'm under the impression that starting the new release is always a bit ... delayed
[18:10] <jam> pickscrape: sure, but at least sheep and moose don't look plural, goose geese is always bad
[18:10] <vila> jam: no, in french serie is singular, series is pluaral
[18:10] <vila> plural even
[18:10] <vila> but we have temps (time) which is both singular and plural
[18:11] <vila> and surely a few others, my gf is far better than me in french grammar, I specialized early in computer languages grammars and forget about the rest :)
[18:11] <jam> vila: time as in 'occurrence' or time as in "clock" ?
[18:12] <vila> time as in clock and weather and music
[18:12] <vila> :)
[18:13] <jam> vila:  I always wondered about time as in weather, as spanish has the same thing (Tiempo)
[18:13] <jam> Hace tiempo hay (or something like that) is how is the weather
[18:14] <jam> Que tiempo hace ?
[18:14] <jam> man my spanish is bad
[18:14] <beuno> jam, que tiempo hace is pretty good  :)
[18:16] <vila> my daughterS also suggest: nez (nose), souris (mouse), vers (rhyme)
[18:16] <vila> tapis (carpet) and generally all words ending with 's' :)
[18:17] <vila> gee, the things they learn at school today....
[18:18] <vila> jam: funny, time passing express both the clockl and the weather for me...
[18:18] <jam> vila: sure, as an English person they seem very different, but I think most Latin languages mix them
[18:20] <jam> Just that "what time is it" is very different to me than "how is the weather"
[18:21] <jam> In arabic, they actually ask "Which hour is it"
[18:21] <jam> vila: to your earlier question, the "mark a new series" may be in the release documents, but they are also rather long
[18:21] <jam> There are quite a few steps, and it is pretty easy to miss some
[18:22] <jam> I think we have to register the release in about 4+ different places (freshmeat, pypi, Bazaar home page, bazaar-announce@, etc)
[18:23] <jam> Also, if it isn't there I just create one
[18:23] <jam> NEWS bothers me more
[18:23] <jam> because you have to wait for it to merge to mainline, and then merge it back into your simple bugfix branch
[18:24] <jam> or run into merge conflicts because 2 people created the new NEWS section
[18:25] <vila> yeah, we have less conflicts in NEWS since we sort it inside each section, but still...
[18:27] <jam> vila: right, especially after a release when all the sections are empty
[18:27] <vila> "what time is it" and "how is the weather" *are* also different in french, yet, in a movie, I often saw clouds moving faster than normal used to represent some time passing, that's the image I was referring to
[18:28] <vila> jam: exactly :) Got bitten recently :)
[18:28] <jam> vila: that is very common in movies, but I only view it as time sped up, you can do it with people walking fast, clock hands spinning quickly, etc
[18:29] <jam> actually, I think one of the downsides is that we are slightly more likely to merge something into an "old" release
[18:29] <jam> when it used to conflict all the time, you would fix it and put it in the right location
[18:29] <jam> now older patches can quietly claim to fix old releases
[18:30] <vila> jam: Yeah, I'm always afraid of that when working in long lived branches :-/
[18:31] <vila> and I'm quite surprised I never made a mistake there (or may be I did and nobody noticed :-( )
[18:31] <jam> vila: I *try* to be careful when I merge. And certainly for a release we should do "bzr diff -r branch:../last-release"
[18:32] <jam> One thing I actually snuck in on this release were tags for '1.5rc1' and '1.5' final
[18:32] <jam> though they didn't seem to propogate to bzr.dev for some reason
[18:32] <jam> propagate
[18:33] <lifeless> woo
[18:33] <lifeless> .revisions and .signatures in use, no more _revision_store
[18:33] <lifeless> all tests passing
[18:33] <lifeless> jam: quirk for you
[18:33] <jam> lifeless: what was your 'write_revision_string' comment?
[18:33] <lifeless> jam: in repository.get_revision_xml
[18:33] <vila> go go... go  lifeless go go :)
[18:34] <lifeless> jam: if you change it from using a stringIO to do _serializer.write_revision_to_string(), the non_ascii tests fail
[18:35] <jam> lifeless: I *think* that is a bug in cElementTree.tostring versus ElementTree.write(f, 'utf-8')
[18:35] <jam> lifeless: not sure, though
[18:36] <jam> lifeless: you have to pass 'encoding=XXX' to tostring()
[18:37] <jam> so I think you need
[18:37] <jam> [18:37] <jam> --- bzrlib/xml_serializer.py    2008-03-28 02:10:23 +0000
[18:37] <jam> +++ bzrlib/xml_serializer.py    2008-05-19 17:36:50 +0000
[18:37] <jam> @@ -87,7 +87,7 @@
[18:37] <jam>          self._write_element(self._pack_revision(rev), f)
[18:37] <jam>      def write_revision_to_string(self, rev):
[18:37] <jam> -        return tostring(self._pack_revision(rev)) + '\n'
[18:37] <jam> +        return tostring(self._pack_revision(rev), encoding='utf-8') + '\n'
[18:37] <jam>      def read_revision(self, f):
[18:37] <jam>          return self._unpack_revision(self._read_element(f))
[18:37] <jam> lifeless: that is my guess, at least
[18:39] <jam> lifeless: is get_revision_xml() used in anger anywhere? I think it used to be the basis for get_revision() but now it is defined in terms of get_revision
[18:39] <gour> where can one see what do you cook for 1.6?
[18:39] <gour> to, at least, smell it a bit
[18:39] <lifeless> bzr.dev
[18:41] <gour> lifeless: i did not mean to 'cook', just to smell ;)
[18:42] <lifeless> yes,I understand
[18:51] <LeoNerd> bzr tags --help     suggests a --sort=ARG  argument, but doesn't give a hint on what ARG can be
[18:53] <lifeless> LeoNerd: ugh, indeed
[18:53] <jam> lifeless: this is the bug with option formatting
[18:53] <jam> where someone wanted a flag to always be true
[18:53] <jam> but that allows "--foo" isntead of just "--sort=foo"
[18:53] <jam> And the person who wrote the first patch didn't step up to fix the help formatter
[18:54] <jam> so that you can get the sub-info when the setup is False
[18:54] <jam> I don't remember the specific variables
[18:55] <dato> the person that wrote the first patch provided an initial patch to fix the help formatter which went uncommented :P
[18:56] <dato> but at this point I guess it may be time to do what somebody proposed on the list a bit ago: use value_switch=True everywhere...
[18:57] <jam> dato: but that allows '--foo' which isn't what we want
[18:57] <jam> bzr tags --date
[18:57] <jam> rather than 'bzr tags --sort=date'
[18:58] <dato> particularly, isn't what *I* wanted. I couldn't stand the idea of tags --date, so that's why I used value_switch=False, knowing the options would be undocumented...
[18:59] <jam> anyway /away lunch
[19:22] <TheSheep> Hello. I want to a vcs for storing versioned data in my python app. Would it be easy to import some part of bazaar and use it internally? Does bazaar require a working tree to really exist on the disk?
[19:23] <TheSheep> s/a vcs/use a vcs
[19:23] <jelmer> TheSheep: you should be able to use the VersionedFile API
[19:23] <jelmer> TheSheep: If you use the Knit implementation it would just create two files on disk (one for the index, one for the actual data)
[19:25] <TheSheep> jelmer: the thing is, I want to make the commits from different users in the app look like commits from different branches, without having to physically create a copy of the repository
[19:29] <lifeless> jelmer: there is no VersionedFile api once my branch lands :P
[19:29] <lifeless> TheSheep: yes you can do that
[19:29] <jelmer> TheSheep: ah, ok. I misunderstood then
[19:29] <lifeless> TheSheep: we do it ourselves in the test suite using MemoryTree's
[19:30] <TheSheep> great
[19:30] <TheSheep> thank you
[19:55] <TheSheep> hmm... so memorytree.get_file will create a StringIO object, or will it actually create a file somewhere in the filesystem?
[20:29] <Pilky> if I create a project on launchpad, does that automatically create a bazaar repo that I then just have to push my initial branch to?
[20:30] <beuno> Pilky, you just have to push
[20:30] <beuno> it creates it when you push
[20:30] <Pilky> cool, thanks
[20:38] <beuno> http://kubasik.net/blog/2008/05/19/bazaar-and-its-rockage/
[20:38] <beuno> :)
[20:53] <Pilky> beuno: I think one of the biggest benefits of bazaar is that it isn't built upon the idea that there is "one true way"™ of doing things
[20:53] <LeoNerd> bazaar is the mechanism, not the policy
[20:53] <beuno> Pilky, yes, they really got that right...
[20:53] <Pilky> the fact that you can get all the benefits of centralised and all the benefits of distributed as and when you need them is pretty damn useful
[20:55] <Pilky> though to be honest, having a disk image installer for OS X with a really nice background is what got me most ;)
[20:55] <Pilky> I'm a sucker for the little things
[20:55] <beuno> hahah
[20:56] <beuno> that's the benefits of a great community  :)
[20:56] <gour> can one use some of launchpad features by not sharing the code? we would like to work on something before opening it to the public...you know that: "premature forking is the root of all evil " :-)
[20:57] <beuno> gour, well, can can *not* upload the code
[20:57] <beuno> I don't know how that works along the lines of policy, but it's certainly possible
[20:58] <gour> ok, then we might wait a bit before using launchpad by using our own roundup tracker
[20:59] <beuno> gour, if it's going to be open source, I don't see a problem with it at all
[21:00] <Pilky> hmm, ok, I think I might be a little confused by --no-trees... my branch doesn't seem to want to let me do anything
[21:01] <gour> beuno: it will be, of course, open-source, most probably GPL
[21:01] <Pilky> what exactly is the benefit of --no-trees, besides being able to put branches in branches?
[21:01] <beuno> gour, than I'd say go for it
[21:01] <gour> Pilky: i read in the user-reference about using --no-trees and then switching checkouts around
[21:01] <gour> beuno: cool. thanks
[21:06] <Pilky> ah, I think I understand it now, --no-trees is for when you're not working on something, just when you're hosting it and don't need the extra editing related stuff
[21:12] <sabdfl> Pilky: yes, exactly
[21:12] <sabdfl> on my laptop, i have a directory ~/foo/ which is a repository of branches of foo
[21:12] <sabdfl> so ~/foo/trunk and ~/foo/feature1 and ~/foo/feature2
[21:13] <sabdfl> and each of those branches has all the files in it
[21:13] <sabdfl> so i can just cd into the branch, and work / hack / merge / commit
[21:13] <sabdfl> on a server, i have a repo ~/foo-storage/
[21:14] <sabdfl> and i have setup my ~/.bazaar/locations.conf so that i can automatically push a branch to the server
[21:14] <sabdfl> just cd ~/foo/feature1; bzr push
[21:14] <sabdfl> and it automatically goes to the server ~/foo-storage/feature1
[21:14] <sabdfl> and creates that branch on the server if it does not yet exist
[21:14] <sabdfl> but on the server i don't need the "working directory"
[21:14] <sabdfl> just the revision history
[21:14] <sabdfl> so that's a --no-trees repo
[21:14] <sabdfl> make sense?
[21:15] <Pilky> yeah
[21:15] <sabdfl> it's really easy to setup
[21:15] <Pilky> was just a little confused by a bit of the documentation that says that Bazaar recommends using --no-trees, but looking at it now I see that it relates to shared repositories
[21:15] <sabdfl> in ~/.bazaar.conf:
[21:16] <sabdfl> [/home/mark/foo]
[21:16] <visik7> good evening
[21:16] <sabdfl> public_branch = bzr+ssh://server.my.com/home/mark/foo-storage
[21:16] <visik7> I can't figure out the difference between init and init-repo
[21:17] <sabdfl> push_location = ﻿bzr+ssh://server.my.com/home/mark/foo-storage
[21:17] <visik7> I've a project without any vcs
[21:17] <sabdfl> push_location:policy = appendpath
[21:17] <sabdfl> and voila
[21:17] <Pilky> sabdfl: cool, thanks
[21:17] <sabdfl> np
[21:17] <Pilky> visik7: I had that problem yesterday, let's see if I can explain it
[21:17] <sabdfl> visik7: init-repo gives you a shared repo
[21:17] <sabdfl> go ahead Pilky :-)
[21:17] <gour> Pilky: see this "Another possible use for a checkout is to use it with a treeless repository containing your branches, where you maintain only one working tree by switching the master branch that the checkout points to when you want to work on a different branch."
[21:18] <visik7> Pilky: you have my attention
[21:18] <Pilky> visik7: if you use init-repo it creates a shared repository for all revision info
[21:18] <Pilky> then you use init to create a branch
[21:18] <Pilky> and essentially all that is stored in that branch are the revision numbers
[21:19] <Pilky> which reduces disk space and improve performance
[21:19] <visik7> Pilky: so if I need to devel my proj splitting and merging a repo is better than a branch
[21:20] <Pilky> well, no, you're developing in a branch, the repo is just a sort of efficient container for many branches
[21:20] <sabdfl> if you will have lots of branches of the same code, then use a shared repo
[21:20] <sabdfl> make a directory structure like this:
[21:20] <sabdfl>  - repodir
[21:20] <visik7> but if I've already started a branch how can I import it into a repo ?
[21:20] <sabdfl>     - branch 1
[21:20] <sabdfl>     - branch 2
[21:21] <sabdfl>     - branch 3
[21:21] <Pilky> visik7: branch it off into the repo
[21:21] <sabdfl> that's each
[21:21] <sabdfl> mkdir ~/my-repo
[21:21] <sabdfl> cd ~/my-repo
[21:21] <sabdfl> bzr init-repo
[21:21] <sabdfl> then bzr branch ~/path/to/branch branch
[21:21] <sabdfl> you will then have:
[21:21] <sabdfl>  ~/my-repo
[21:22] <sabdfl>    [this is where the revisions are all stored, shared, in .bzr]
[21:22] <sabdfl>  ~/my-repo/branch
[21:22] <sabdfl>    [this is where the working files for this branch are]
[21:22] <sabdfl> and you can make a second branch by going:
[21:22] <sabdfl> cd ~/my-repo
[21:22] <sabdfl> bzr branch branch new-branch
[21:22] <visik7> 'couse I've already branched by project than rebranch and devel new features but outside of a repo
[21:23] <visik7> now I need to branch both inside the repo ?
[21:23] <sabdfl> (eek, calling that first branch "branch" was bad)
[21:23] <sabdfl> the first time you branch "into" a repo, it copies all the revisions into the repo store
[21:23] <sabdfl> from then on, each new branch just re-uses the previous revisions for everything that's common
[21:23] <sabdfl> which is most of history, usually
[21:23] <sabdfl> say you have a project with 1000 commits
[21:23] <sabdfl> and you make a new branch, with 10 extra commits
[21:24] <sabdfl> that's only 1% "new"
[21:24] <sabdfl> so it makes sense to share history
[21:24] <visik7> yes yes I got it
[21:25] <visik7> but the problem now is that I've 2 branches of a project outside of a repo
[21:25] <visik7> :(
[21:25] <Pilky> visik7: I don't see any problems with branching both into the repo
[21:26] <Pilky> you just need to change the default merge location for when you merge back together
[21:26] <Pilky> so that you're merging back to the copy in the repo, not the one outside of it
[21:32] <visik7> ops
[21:32] <visik7> how can I undo a merge ?
[21:32] <beuno> visik7, bzr revert
[21:33] <pickscrape> As long as you haven't committed yet...
[21:33] <beuno> actually, bzr revert --forget-merges
[21:33] <visik7> fiu
[21:33] <radix> --forget-merges is only if you don't want to revert the changes to the files that the merge made
[21:33] <beuno> yes, if you already committed, then you'll have to specify to which revision to revert  (bzr revert -r -1 would be the last revision)
[21:34] <beuno> radix, oh?  that *doesn't* revert the changes made?
[21:34] <radix> beuno: right. the point of --forget-merges is that it *only* forgets the metadata about the merge, while keeping the changes to the files.
[21:35] <beuno> radix, hrm, I wonder if that's the best name for it...
[21:35] <visik7> I'm really really new to vcs concepts, I was expect some question when I run a merge, instead it do all the work but what really a merge do ?
[21:35] <visik7> a part from coping files ?
[21:37] <Pilky> visik7: well, if there are no conflicts then it should perform the merge for you
[21:37] <Pilky> which merges directories, but also the files themself
[21:37] <Pilky> say you edited line 5 of a.txt in one branch and then line 20 of a.txt in another branch
[21:38] <Pilky> when you merge them it will try to put the new stuff in line 5 and line 20 into a.txt
[21:38] <radix> visik7: it does more than just copying. It "merges" in all the changes made in another branch, without overwriting other changes that have been made otherwise.
[21:39] <Pilky> of course, if you were to edit line 5 in both branches and try to merge, you'd get a conflict as there are two new bits of data and the VCS doesn't know which to choose
[21:39] <visik7> anyway it's request to manually check if everythings works as expected right ? 'couse it can't be aware of what my code relies  on
[21:39] <Pilky> in this case you'll have to choose yourself and then resolve it
[21:40] <radix> visik7: This is why bzr doesn't automatically *commit* the changes when you merge --
[21:40] <radix> visik7: you have a chance to review the changes with "bzr diff" before running "bzr commit".
[21:40] <visik7> good, clear
[21:45] <mtaylor> bzr: ERROR: Invalid revision number 447
[21:45] <mtaylor> when pushing a just-merged branch back to launchpad
[21:45] <mtaylor> what does that mean?
[21:49] <mtaylor> nm - I think it was a local hook
[21:50] <mwhudson__> mtaylor: interesting, we've had a few branches with that problem
[21:51] <mtaylor> mwhudson: oh, ok. then it _wasn't_ my fault :)
[21:51] <mwhudson> mtaylor: can you check 'bzr revno' vs 'bzr revision-history | wc -l' ?
[21:51] <mwhudson> they should give the same number
[21:51] <mwhudson> mtaylor: well, maybe it was :)
[21:51] <mtaylor> mwhudson: they equal
[21:51] <mwhudson> mtaylor: oh good
[21:51] <mtaylor> then it was my fault
[21:52] <mwhudson> it's possible
[21:52] <mwhudson> mtaylor: which branch?
[21:52] <mtaylor> mwhudson: lp:ndb-connectors
[21:52] <mtaylor> gah
[21:52] <mtaylor> lp:ndb-bindings
[21:53] <mwhudson> hm, branch on lp seems ok too
[21:54] <mwhudson> so i don't know what you did, but it doesn't seem to be related to our mystery branch problem
[21:54] <mwhudson> good news for you :)
[21:54] <mtaylor> yay!
[21:58] <schmichael> just upgraded to 1.5 and a commit seems to be frozen on pre_commit hooks (stage 3/5)
[21:58] <schmichael> afaik i have no pre_commit hooks
[21:59] <schmichael> anybody know where i should start looking to fix this?
[22:04] <schmichael> i hit ctrl-c, and it seems to have committed just fine
[22:05] <schmichael> now bzr push appears frozen (ssh+bzr protocol, bzr 1.5 on the server as well)
[22:08] <schmichael> i had also run bzr upgrade on both branches... perhaps thats the problem?
[22:12] <LaserJock> jelmer: around?
[22:13] <jelmer> LaserJock: hi
[22:13] <LaserJock> jelmer: I'd like to upgrade my bzr/bzrtools version to the bzr PPA
[22:13] <LaserJock> but bzr-svn doesn't seem to be ready
[22:13] <LaserJock> can I get bzr-svn from a bzr branch instead?
[22:15] <schmichael> argh!  i'm trying to commit with the old copy of my repo, and it still doesn't work
[22:15] <schmichael> what have i done to break bzr 1.5? :(
[22:15] <jelmer> LaserJock: yes, just use the 0.4 branch
[22:16] <schmichael> hm, i have bzr-svn and bzr 1.5 installed... could that be the problem?
[22:16] <jelmer> schmichael: that shouldn't matter
[22:17] <jelmer> do you have any other plugins installed?
[22:17] <schmichael> any package that starts with bzr- in debian sid
[22:18] <schmichael> dbus, email, gtk, pqm, rebase, svn, tools
[22:18] <schmichael> i probably only use gtk, svn, and tools though
[22:22] <schmichael> huh, it appears my push did succeed
[22:25] <schmichael> well, i guess everything is working well enough
[22:25] <schmichael> i just have to hit ctrl-c to kill commits at the pre_commit hook stage
[22:25] <schmichael> for pushing, i guess just count to ten and hit ctrl-c
[22:25] <schmichael> i'd love to file a bug but i don't have any clue where to even start diagnosing this
[22:30] <beuno> schmichael, you downloaded the bzr 1.5 tarball?
[22:30] <schmichael> beuno: using debian sid packages on my desktop and easy_installed 1.5 tar ball on my etch server
[22:31] <schmichael> bzr push on my desktop shows 'Using saved location ...', the doesn't-update-working-copy warning, then '/ (0,0)' displays briefly
[22:31] <schmichael> that disappears and it just hangs
[22:32] <schmichael> the push has already completed (its on the server), so i just hit ctrl-c to exit
[22:33] <beuno> schmichael, can you take a look at the ~/.bzr.log?
[22:33] <beuno> there might be some information there
[22:36] <schmichael> beuno: thanks for the tip, this looks revealing: http://pastebin.com/m310f07c6
[22:36] <schmichael> seems the dbus plugin is to blame?
[22:37] <LaserJock> hmm, can you use bzr-svn to separate svn branches into separate bzr branches in a shared repo?
[22:37] <beuno> schmichael, yes it is  :)
[22:38] <schmichael> beuno: removing bzr-dbus fixed it!  thanks!
[22:39] <jelmer> LaserJock: yes
[22:39] <jelmer> schmichael: please file a bug
[22:39] <schmichael> jelmer: with debian?
[22:39]  * schmichael hates debian's bts
[22:40] <beuno> schmichael, you're welcome  :)
[22:40] <beuno> jelmer, is a bug in order?  he's not using bzr from the debian repo
[22:40] <LaserJock> jelmer: I'm trying  bzr svn-import --all --trees <svn repo>, would that work?
[22:40] <schmichael> beuno: i am actually
[22:40] <schmichael> locally its from debian sid
[22:40] <LarstiQ> schmichael: the easy_installed one?
[22:40] <schmichael> LarstiQ: nope, that one works fine (no dbus plugin installed on the server)
[22:41] <schmichael> sorry for the confusion
[22:41] <schmichael> its only on my debian sid desktop using debian's bzr 1.5 packages
[22:42] <jelmer> LaserJock: yes
[22:43] <LaserJock> jelmer: how do I then update my branches? bzr pull ?
[22:44] <LaserJock> I'm a little confused as to the relationship between svn-import and just using bzr branch <svn repo>
[22:45] <jelmer> LaserJock: yes
[22:45] <jelmer> LaserJock: think of "bzr svn-import" as a series of "bzr branch" commands
[22:45] <LaserJock> ahhh
[22:49] <LaserJock> jelmer: wow, that's pretty sweet
[22:50] <LaserJock> jelmer: is there a way to update the whole shared repo?
[22:50] <jelmer> LaserJock: only the existing branches in the repo
[22:50] <jelmer> "bzr multi-pull"
[22:51] <jelmer> although "bzr svn-import" should work incrementally as well
[22:51] <LaserJock> yeah, ok I think this is perfect
[22:52] <LaserJock> I won't be pull'ing tags and usually only one branch at a time anyway, but multi-pull is just what I was looking for
[23:02] <poolie> good morning
[23:03] <jam> morning poolie
[23:04] <beuno> mornin' poolie
[23:04] <poolie> jam, hi, we were going to talk now iirc
[23:04] <poolie> hello beuno
[23:05] <jam> poolie: I'm sure you're right, I should get this on my schedule :)
[23:07] <jam> poolie: I have skype, and I'm ready when you are
[23:07] <visik7> morning ?
[23:07] <poolie> morning visik7
[23:08] <visik7> where are u ?
[23:08] <poolie> sydney
[23:09] <visik7> cool I was there last summer
[23:11] <visik7> but too much one way only roads for my liking
[23:36] <TheSheep> does bzr allow me to save metainformation on files? like, for example, a comment?
[23:38] <mwhudson> TheSheep: no
[23:40] <TheSheep> mwhudson: thanks
[23:40] <beuno> TheSheep, of course, there is some potention for a plugin there...
[23:40] <beuno> you might want to mail the list and see if someone catches on with it  ;)
[23:41] <TheSheep> beuno: nah, it's not that important
[23:41] <TheSheep> beuno: besides, my use case is far from common
[23:43] <beuno> well, bzr is all about uncommon use cases, but, I won't insist
[23:44] <Peng> Googlebot is having lots of fun downloading all of my knits. :)
[23:44] <beuno> mueheheh
[23:44] <beuno> should be interesting to see what they do with that
[23:54] <Peng> It already indexes some bundle files, and occasionally people search for weird things and find them.
[23:55] <LaserJock> dang, bzr multi-pull is so sweet
[23:56] <igc> morning
[23:56] <LaserJock> I was just going to write shell scripts to go through and update all my VCS checkouts
[23:56] <LaserJock> for bzr all I have to do is cd bzr/ && bzr multi-pull
[23:56] <jam> morning igc
[23:57] <beuno> heya igc