=== AdamdV is now known as AdamDV
[00:11] <sili> We have a team here in the states and another team in the Philippines. The problem with accessing a shared bzr repo is that there's a lot of latency when accessing from the philippines. Can anyone suggest a work flow that would allow us to access the remote repositories less frequently but still keep changes mirrored?
[00:12] <AuroraBorealis> if you branch it (instead of just checking out) then it uses the local branch until you commit
[00:13] <AuroraBorealis> or update / whatever
[00:13] <sili> branching is still quite slow over SSH. Is there a way to maintain the repositories with some kind of push/pull?
[00:14] <sili> one repository at each site, then sync somehow
[00:15] <AuroraBorealis> thats what branching does.
[00:15] <AuroraBorealis> you branch it once
[00:15] <AuroraBorealis> then bind it to the place you just branched from
[00:15] <AuroraBorealis> then you make your changes, and it commits back to the repo
[00:16] <AuroraBorealis> and then the branch essentially is a mirror of the repo
[00:40] <sili> hmm
[00:40] <sili> branching is still slow
=== bradm_ is now known as bradm
[04:54] <djzielin> still having problems with bzr
[04:55] <djzielin> the issue I had in June just happened again.
[04:55] <djzielin> namely I commit changes is some very small files.
[04:55] <djzielin> I issue the commit command...
[04:55] <djzielin> it shows the several small source code files that I modified.
[04:55] <djzielin> and then it uploads the entire branch
[04:56] <djzielin> which is 200+ MB
[04:56] <djzielin> why does this happen?
[04:57] <djzielin> I'm using sftp to a remote computer
[05:01] <lifeless> becaues you're using sftp
[05:01] <lifeless> it has to manage the database on disk using just file operations, and part of database operation is a 'pack' which will happen every power-of-10 commits.
[05:01] <lifeless> you should use bzr+ssh. *much* better.
[05:21] <djzielin> okay
[05:22] <djzielin> I'll change the branch.conf file
[05:24] <djzielin> thanks for the help!
[05:44] <AuroraBorealis> can anyone else browse code on launchpad? i'm getting 503's ;<
[05:50] <lifeless> should be fixed
[06:26] <vila> hi all
[06:27]  * fullermd vilas at wave.
=== Quintasan_ is now known as Quintasan
[06:32] <vila> :)
[06:33] <vila> udd hackers: interesting failure when running import_package.py locally for tests: http://paste.ubuntu.com/675052/
[06:33] <vila> two remarks on that:
[06:34] <vila> 1) jubany doesn't use pycurl so we see a different error (probably caught as a socket error instead of a Connection error, may be (or not) worth fixing)
[06:35] <vila> 2) The librarian may  dislike being queried for an arbitrary url
[06:36] <vila> all in all, refresh_possible_transports is more brittle than expected, I wonder how we should make it more robust
[06:36] <fullermd> Man, things get worse with age.  Used to be, librarians just didn't like you talking...
[06:37] <vila> hehe
=== 31NAAXP81 is now known as wallyworld_
[06:45] <fullermd> Funny.  That makes me wonder if this library card I have still works...
[08:26] <benste> hi there - i took part in this years GSOC and now i need to know how i could get one big Diff file which includes all changes which I made to a branch
[08:26] <benste> how can i do this ?
[08:27] <benste> PS: - talking about lp:mailmanwebgsoc2011
[08:42] <vila> benste: find the first revision your're interested in then bzr diff -r<first_revno - 1>..
[08:42] <benste> thanks
[08:43] <fullermd> Alternately: do you really want "diff of all my revisions", or do you really want "my changes relative to upstream"?
[08:44] <benste> fullermd: i do want to have all my changes i did during Gsoc --  used bzr blame atm.
[08:44] <benste> fullermd: if you do have something for all MY changes - that would be best
[08:46] <fullermd> If you do something like "bzr diff -rancestor:<url of upstream trunk, or whatever you base your work off of>.." you'll wind up with "what I've changed relative to upstream"
[08:46] <vila> benste: did you commit all your changes to a local branch before merging them upstream ?
[08:46] <fullermd> Which will be more meaningful if e.g. you've merged upstream changes as part of your work.
[08:46]  * vila nods
[08:47] <benste> I've commited all my changes in about 150 commits
[08:47] <benste> which are all upstream
[08:47] <benste> but there are a few in between which are made by other persons
[08:47] <AuroraBorealis> the merge that took your changes and merged them upstream will probably have all differences
[08:47] <AuroraBorealis> look for that commit in the upstream branch
[08:48] <vila> AuroraBorealis: only if he merged them all at once
[08:48] <AuroraBorealis> is it possible to combine multiple diffs?
[08:48] <AuroraBorealis> ive never seen that done
[08:48] <vila> benste: hence my question, did you commit all your changes on s a single branch or did you create multiple branches ?
[08:49] <benste> vila: i do only want to have the changes in one upstream branch which is lp:mailmanwebgsoc2011
[08:49] <vila> AuroraBorealis: oh yes, you certainly did but didn't realize it ;) bzr handles snapshots so when you ask for a diff between two snapshots you get a diff that can encompass multiple revisions
[08:50] <vila> benste: there are various ways to get that, I'm searching for the easiest first
[08:50] <AuroraBorealis> does that work for revisions that are not sequential?
[08:50] <AuroraBorealis> like revisions 1, 2, 4, 7?
[08:51] <vila> it depends on whether you can find the right snapshots...
[08:51] <vila> or revisions
[08:52] <AuroraBorealis> well on his own branch
[08:52] <AuroraBorealis> or rather the upstream branch
[08:53] <AuroraBorealis> cant you do like for each revision (that he commited): get the diff of it and combine it?
[08:55] <AuroraBorealis> that seems easiest
[08:55] <vila> bzr log -l 25 --match-author '.*Vincent.*' -n0 -p
[08:56] <vila> doesn't combine but shows all my commits
[08:56] <AuroraBorealis> yeah, but now you need a combined diff for all of those commits
[08:56] <AuroraBorealis> i'm not too familiar with diffs so i have no idea how you combine them
[08:56] <vila> you can't
[08:56] <AuroraBorealis> you can't with bzr or is it just not reasonable to have a combined diff of multiple commits
[08:57] <vila> that's why I'm asking for some branch which may contain the right revision that can then be used to this combined diff
[08:57] <vila> what is the use case ?
[08:57] <AuroraBorealis> probably showing to employers / google sumer of code people what exactly you did
[08:58] <AuroraBorealis> although a huge combined diff might not be the best way to visualize that, since if you create some code, then edit it, it would just show that you added it? i dunno
[08:58] <vila> I can't think of way to combine arbitrary diffs, short of creating a branch with all these revisions either already there (and only them)
[08:58] <AuroraBorealis> it seems that you need the diff from the merge into the upstream branch
[08:58] <vila> such a branch can be created by cherry-picking all these revs though
[08:59] <AuroraBorealis> that way it shows code that is new, and what code you edited that was already there
[08:59] <fullermd> vila: First you import it into darcs...   :p
[08:59] <vila> fullermd: then you wait for the universe to cool down a bit ;)
[09:00] <AuroraBorealis> to do this you would probably have to merge diffs. which would in turn create diffs.
[09:00] <AuroraBorealis> INCEPTION
[09:00] <vila> AuroraBorealis: yes, but you imply that a single merge was done, I doubt it's the case
[09:00] <fullermd> The universe cooling down would be nice...
[09:00] <AuroraBorealis> svn has a 'combinediff' plugin
[09:02] <vila> AuroraBorealis: how does it deal with conflicts ?
[09:02] <AuroraBorealis> looking at the source
[09:02] <AuroraBorealis> which is C which i don't know very well
[09:02] <vila> AuroraBorealis: and with renames ?
[09:03] <vila> AuroraBorealis: and so on :)
[09:03] <AuroraBorealis> http://cyberelk.net/tim/data/patchutils/stable/patchutils-0.3.2.tar.bz2
[09:03] <vila> benste: so, rolling back a bit, what's your need ?
[09:04] <benste> vila: sry was a little while afk
[09:04] <benste> - i need to submit all my code to google
[09:04] <vila> benste: as a single patch or is a series of patches good enough ?
[09:05] <vila> if series is good enough, 'bzr log -p' is your friend
[09:05] <AuroraBorealis> and god i hate C
[09:06] <AuroraBorealis> i can never find where the code i actually want is :<
[09:06] <vila> and will contain more useful info than a single combined patch (like how many revisions, when, etc)
[09:07] <vila> benste: try playing with "bzr log --match-author '.*benste.*' -n0" first to check you've got all the revisions you want and not more
[09:07] <benste> vila: will try that
[09:08] <benste> -- author name would be my fullname --used for commits correct ?
[09:08] <vila> benste: you may want to tweak -n (aka --levels) depending on your branch history
[09:08] <vila> benste: whatever bzr log display for your commits
[09:09] <AuroraBorealis> bzr log doesn't have match author?
[09:09] <vila> benste: try 'bzr log -n0 -l 32' (tweak 32 until you get of yours, see at what depth (level) it is and use that )
[09:09] <vila> AuroraBorealis: requires >= 2.4 maybe ?
[09:10] <AuroraBorealis> maybe
[09:12] <benste> bzr log does only show the commit messages
[09:12] <benste> had to replace 32 to 162 which includes my first commit
[09:12] <vila> benste: yes, '-p' will show you the diffs
[09:12] <benste> bzr log does show all users commits
[09:12] <benste> not only mine
[09:13] <vila> benste: but first you want to identify only *your* commits with --match-author
[09:13] <vila> s/identify/select/
[09:13] <benste> ???
[09:13] <benste> --mathc author does not exist for log methode
[09:14] <benste> - AuroraBorealis said thsi earlier - can confirm that
[09:14] <AuroraBorealis> im using 2.3 though
[09:14] <vila> benste: !paste the excerpt of your 'bzr log -n0  -l162'
[09:14] <AuroraBorealis> might exist for a later version
[09:14] <vila> !paste
[09:14] <ubot5> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
[09:14] <vila> AuroraBorealis: yes, hence >= 2.4
[09:15] <benste> http://paste.ubuntu.com/675112/
[09:15] <benste> I've used 163 to include a revision which is not mine
[09:16] <benste> - the oldest one is my demo that it's not filtered
[09:16] <vila> so, "bzr log -n0 -l 163 --match-author benste"
[09:17] <benste> vila: benste@benste-vpc-sb1c5e:~/Projects/Mailman/mailman_django$ bzr log -n0 -l 161 --match-author benste
[09:17] <benste> bzr: ERROR: no such option: --match-author
[09:17] <vila> benste: upgrade to 2.4, what os are you using ?
[09:18] <benste> 11.04 - ubuntu natty
[09:19] <benste> it's 2.3.11
[09:19] <benste> bzr
[09:19] <vila> benste: add the bzr stable ppa to your repositories and update
[09:20] <vila> https://launchpad.net/~bzr/+archive/ppa
[09:20] <AuroraBorealis> is 2.4 stable?
[09:20] <AuroraBorealis> it says that 2.4 is test
[09:21] <vila> not officially released but stable nevertheless, announcement currently blocked waiting for windows installers themselve waiting for bzr-svn to be released, benste shouldn't have to care
[09:22] <vila> benste: click the 'Read about installing' link for detailed instructions
[09:22] <AuroraBorealis> if this breaks my stuff i'm blaming you =P
[09:22] <benste> vila: thanks for the guide - although I'm quite new ot bzr I'm using ubuntu since 5.04 :)
[09:23] <vila> benste: should be roughly 'sudo add-apt-repository ppa:bzr/ppa'
[09:23] <vila> ha cool, congratulations ;)
[09:23] <benste> or open software center and add it in the GUI :) - open update manager and run updates - I'm just installing it
[09:23] <AuroraBorealis> i have as well. installing ppa's should be easier
[09:23] <benste> I know sometimes CLI is faster :)
[09:23] <AuroraBorealis> rather then copy/pasting two links
[09:23] <AuroraBorealis> and then saving the public key to a text file and importing that
[09:24] <benste> -- AuroraBorealis you don't need the key
[09:24] <benste> that done automaticly if you use the software center
[09:24] <AuroraBorealis> if i remember correctly, apt-get yells at you
[09:24] <AuroraBorealis> does it do it automatically now?
[09:24] <vila> benste: \o/ I didn't know SC can automatically add the keys ! Thanks !
[09:24] <AuroraBorealis> http://wiki.bazaar.canonical.com/WindowsDownloads
[09:24] <AuroraBorealis> no 2.4 beta release installer :<
[09:24] <vila> AuroraBorealis: add-apt-repository does
[09:25] <benste> vila: my 2.4 doesn't have match author eitehr !
[09:25] <AuroraBorealis> ive never seen that command before
[09:25] <vila> crap
[09:25] <vila> let me check
[09:26] <fullermd> 's not in 2.4.0...
[09:26] <benste> vila: maybe I'll have to restart first
[09:26] <benste> I've installed
[09:26] <benste> Version: 2.4.0-1~bazaar1~natty1
[09:27] <vila> argh, only available in 2.5dev1 :-(
[09:27] <AuroraBorealis> there should just be a regex style matching thing for log
[09:28] <benste> vila: hopefully you do understand that I woun't install 2.5 on my working machine -- did you ?
[09:28] <vila> benste: why ? That's what I use :)
[09:28] <AuroraBorealis> you can download the source
[09:28] <AuroraBorealis> and then invoke it manually
[09:28] <AuroraBorealis> and not use it for production
[09:28]  * vila searches for a fallback, yeah, AuroraBorealis suggestion could work for a one-shot case
[09:29] <benste> vila: I'm going to ZA for 11 months starting next week - accessing resources like updates or installation media in case of something brakes will be very difficult there
[09:29] <vila> benste: sure thing, was kidding
[09:29] <AuroraBorealis> just download the source onto your desktop
[09:29] <benste> if it's really that easy couldn't I gently ask you to get me this big diff ?
[09:29] <AuroraBorealis> and cd to the directory and just do ./bzr log
[09:30] <benste> btw . did you consider that there will be a lot more Gsoc students asking this in the couple of next weeks ?
[09:30] <AuroraBorealis> well technically
[09:30] <AuroraBorealis> hmm
[09:32] <AuroraBorealis> i still think its really easy to download a temporary copy of 2.5 to generate the log  :3
[09:32] <vila> benste: oh, you want fish ? ;) Here is some: http://paste.ubuntu.com/675122/
[09:32] <vila> benste: does that includes all the wanted revisions ?
[09:33] <benste> looks like this is correctly filtered
[09:33] <benste> now the only thing missing is the code :)
[09:33] <benste> you said -p ?
[09:33] <benste> AuroraBorealis: I'm not that confident which branch / file I'll have to download
[09:33] <benste> I'm stuck on https://launchpad.net/~bzr/+archive/daily?field.series_filter=natty
[09:34] <AuroraBorealis> i just did a bzr branch lp:bzr
[09:34] <vila> benste: uploading
[09:34] <vila> http://paste.ubuntu.com/675124/
[09:35] <benste> 51000 lines of code WOW
[09:35] <benste> many thanks
[09:35] <vila> lines of diff != lines of code ;-)
[09:35] <benste> -- should i write a short how to + need to use bzr 2.5 on the students list ?
[09:35] <AuroraBorealis> yeah
[09:36] <AuroraBorealis> just say "you need 2.5, and to cd to the directory, ./bzr log -p --match-author "something"
[09:36] <vila> benste: sounds like a good idea, but an even better one will be to recommand keeping a pristine branch of your work may be
[09:37] <benste> what's pristine ?
[09:37] <vila> one keeping track of your commits only
[09:38] <vila> which can be merged upstream as you progress (but the merges will occur upstream not locally, keeping a clean branch there)
[09:38] <vila> from this branch, you can get a combined diff with only: 'bzr diff -rsubmit:'
[09:38] <AuroraBorealis> but then dont you have to merge changes from upstream back into your own branch?
[09:39] <vila> errr, sorry, won't work for the parts already merged, what's the right revspec there...
[09:39] <benste> :)
[09:40] <benste> will tell them to use 2.5 and the command we've had earlier
[09:46] <vila> benste: yeah, there is no easy shortcut for such cases which could be used for a simple diff :-/
[09:46] <benste> :)
[09:46] <benste> so, "bzr log -n0 -l 163 --match-author benste"	
[09:46] <benste> many thanks for your help
[09:46] <vila> get rid of the '-l 163' it was just to limit the output while searching for the right range
[09:47] <benste> well I think this might be helpful especially for those who contributed to their project before Gsoc as well
[09:47] <benste> + I've already send the mail to the list
[09:48] <vila> hehe, that last one is definitive ;)
=== AuroraBorealis is now known as aurora|sleep
[11:04] <zyga> hi
[11:04] <zyga> when I'm branching stuff from lp:ubuntu/lucid/package I get strange new messages
[11:04] <zyga> Most recent Ubuntu Lucid version: 2.2.4-1build1
[11:04] <zyga> Packaging branch status: CURRENT
[11:04] <zyga> is that some new feature?
[11:13] <jelmer> zyga: yep
[11:13] <jelmer> vila: finally made some progress on that bzr-svn bug
[11:13] <jelmer> vila: doing the QA for 1.1.0 now
[11:19] <vila> jelmer: hey ! Very quiet around here this morning, I wondered for a minute it was Sunday or something...
[11:19] <vila> jelmer: that's *very* good news !
[11:19] <jelmer> vila: accidentally working during the weekend
[11:19] <jelmer> been there, done that.
[11:19] <jelmer> :)
[11:20] <vila> hehe
[11:39] <jam> zyga: http://doc.bazaar.canonical.com/bzr.dev/en/release-notes/bzr-2.4.html#id4 item 2
=== mrevell is now known as mrevell-lunch
[11:55] <zyga> jam: thanks
[12:04] <vila> jam: you said "most-compatible way for 2.4", how come you did miss the *two* times I said I was talking about bzr.dev not 2.4 ?
[12:12] <jam> vila: I'm still not sure that I would change it for trunk either.
[12:13] <vila> That wasn't the question ;)
[12:14] <vila> But anyway, 6 classes sharing some API and no central place to control it is scary, if you can't introduce a base class, then may be you should add some sort or parametrized tests to limit the possible divergences
[12:18] <vila> grrr, trying to reproduce a failure with an import taking >2 hours only to see it succeeds...
[12:20] <jam> vila: RemoteRepository doesn't inherit from Repository either
[12:20] <jam> we've got a fair history of using duck-typed interface based apis
[12:20] <jam> rather than inheritance based
[12:21] <vila> and you feel ok with code duplicated 6 times and no common tests ?
[12:22] <jam> vila: there really isn't a way to test that Graph acts like Repository, is there?
[12:22] <jam> it isn't duplicated code
[12:22] <jam> since they all implement their history store differently
[12:22] <vila> with respect to get_parent_map ?
[12:22] <jam> vila: yes
[12:22] <vila> so you have the same API behaving in 6 different ways ?
[12:23] <jam> vila: sometimes get_parent_map() takes lists of tuples, sometimes lists of strings, sometimes ...
[12:23] <jam> but Graph can still walk the graph
[12:23] <jam> as long as you pass it things that the underlying parent_map can provide
[12:24] <vila> either it's the same API or it's not
[12:24] <vila> if it's not having the same name is not good
[12:25] <jam> vila: the api is "give me X and I'll return a dict mapping X to its parents"
[12:25] <jam> which they do all conform to
[12:25] <jam> and is why you can use Graph(VersionedFile)
[12:25] <jam> or Graph(Repository)
[12:25] <vila> good, if they conform, they can be tested
[12:25] <jam> even though the former thinks of "keys" and the latter of "revision_ids"
[12:25] <jam> vila: they're all pretty well tested, just not grouped
[12:26] <vila> that's the point
[12:26] <vila> if they aren't grouped they can (and will) diverge
[12:26] <jam> vila: they haven't in 5-ish years...
[12:27] <vila> sorry ?
[12:27] <vila> I thought you just changed at least one of them ?
=== mrevell-lunch is now known as mrevell
[12:46] <vila> jam: if you don't want to address that *now*, I don't have *any* issue with that, but at least file a bug while all the needed bits are paged-in, you've just demonstrated how vital this piece of code is (dropped from 2hrs down to 54s) and how a bug can have a huge impact here. You can't just hope that nothing else will need the same amount of effort to debug.
[13:00] <lag> Is there a way to delete logs in bzr?
=== yofel_ is now known as yofle
=== yofle is now known as yofel
=== beuno is now known as beuno-lunch
=== cbz_ is now known as cbz
[15:55] <skraps> help get SSL options for everyone for free on pastebin like this page on face book http://pastebin.com/f4e0diQP
=== tchan1 is now known as tchan
=== beuno-lunch is now known as beuno
=== deryck is now known as deryck[lunch]
=== deryck[lunch] is now known as deryck
[18:08] <vila> jelmer_: \\o \o/ o// \\o \o/ o//
[18:08] <jelmer_> vila: :)
[18:20] <cheater> hi!
[18:20] <cheater> i have a problem but i don't know how to properly describe it
[18:20] <cheater> basically i have a "huge" bzr repo
[18:20] <cheater> i would like to take one directory out of it and put it up on bitbucket
[18:21] <cheater> which uses hg
[18:21] <cheater> what is the best way to do that?
[18:21] <cheater> i would like to have bidirectional communication between the two
[18:22] <cheater> is that what you call an "external" or something to this effect?
[18:25] <jelmer_> cheater, probably using bzr-fastexport + hg-fastimport
[18:26] <cheater> is this something i have to "run" every time i update the one or the other?
[18:26] <jelmer_> cheater, yep
[18:27] <jelmer_> cheater, it would probably be one way
[18:27] <cheater> will doing bzr up "run" it?
[18:27] <jelmer_> no
[18:28] <cheater> hmmmm
[18:28] <cheater> i wish bitbucket just had bzr support :(
[18:29] <jelmer_> cheater, it's likely something like what you're asking for will be supported in the future when either bzr-hg is improved or support for externals lands in the core
[18:29] <jelmer_> gtg, back later
[18:29] <cheater> thanks
[19:45] <yshavit> hi everyone... bzr push (and merge) say I have uncommitted changes, but bzr st doesn't list anything, and bzr ci tells me there's nothing to commit. Any ideas?
[19:46] <yshavit> (I expect there to be nothing to commit, btw -- it's push/merge that I believe are "broken", though it's probably pebkac)
[19:47] <yshavit> and also, when I check on lp, the most recent version is indeed the one I most recently committed
[19:50] <yshavit> Oh, hm. I did a bzr ci --unchanged and it complained about three missing files and then forced the no-op commit through, now it all works. I think my IDE was the broken link.
=== medberry is now known as med_out
=== med_out is now known as medberry