[00:02] <hicham> anybody in here ?
[00:03] <nailuj24> nah
[00:04] <hicham> how can i reduce the revision size when checking out a repo ?
[00:04] <hicham> any hint nailuj24 ?
[00:06] <nailuj24> hmm, i don't know, but someone in here probably does
[00:06] <nailuj24> let's just wait a little :)
[00:08] <methods> can i push to a checkout and have it instantly cause the checkout to update ?
[00:09] <hicham> if bzr forces everybody to download the whole history then that is just weird
[00:10] <nailuj24> hicham: it's the way most dcms' work
[00:11] <hicham> nailuj24 : not git anyway
[00:11] <hicham> nailuj24 : in git we have the --depth switch
[00:11] <nailuj24> hicham: not? how do you revert to an older version then?
[00:11] <nailuj24> ah i see, never mind
[00:12] <nailuj24> i'm sure this is possible somehow
[00:13] <hicham> i don't know why canonical is duplicating efforts
[00:14] <hicham> they created bazaar to make our life more complicated
[00:14] <nailuj24> lol
[00:15] <nailuj24> they created bazaar to make a good and easy-to-use dvcs
[00:15] <nailuj24> and cross platform, by the way
[00:15] <hicham> what was first git or bzr ?
[00:16] <nailuj24> bzr i suppose, but let me google it :)
[00:16] <Nafai> hicham: I'm pretty sure bzr was started first, but it didn't meet the kernel team's needs, so they started git
[00:16] <Nafai> and bzr is derived from earlier efforts, going back to Tom Lord's tla
[00:17] <nailuj24> bzr was 1 month earlier
[00:17] <mzz> 1 month? that doesn't sound right
[00:17]  * mzz checks
[00:18]  * nailuj24 is taking his info from http://www.infoq.com/articles/dvcs-guide
[00:18] <hicham> well, can somebody tell me how to reduce the revision log downloaded ?
[00:19] <hicham> i get more than 100Mb for 5Mb of sources !
[00:19] <mzz> mmm, git's older than I thought then.
[00:21] <hicham> canonical as always is wasting money on duplicate stuff
[00:21] <hicham> bzr, launchpad, notify-osd ...
[00:21] <mzz> there might be a way to do what you want using stacked branches, but I'm not sure (and definitely don't know how)
[00:23] <nailuj24> hicham: well, if the new solution is better than the original one
[00:24] <hicham> nailuj24 : i don't know, they develop solutions for internal use only
[00:24] <hicham> nailuj24 : not like redhat
[00:25] <mzz> you're not making sense
[00:25] <Nafai> hicham: canonical is more than happy to share things up upstream
[00:25] <mzz> notice how bzr and notify-osd have always been open source and launchpad is now also open source
[00:25] <Nafai> hicham: In fact I was just hired to work on converting some things to a new application indicators api and I am going to do my best to get things upstream
[00:26] <mzz> also, please try to keep this channel about bzr, not about how canonical should encourage open source development.
[00:26] <hicham> mzz : sorry, sorry, i am just a little bit frustrated with bzr, not familiar with it
[00:26] <mzz> hicham: I feel the same way about those silly projects using git :P
[00:26] <Nafai> hicham: me too, used to git, but I'll get used to it :)
[00:27] <RAOF> hicham: To answer your actual question - you can use “bzr checkout --lightweight” to get svn-like behaviour.  That is, you'll only have the current revision locally.
[00:27] <hicham> RAOF : thanks a lot !!!
[00:27] <mzz> that's not quite svn-like, since you also don't have the *current* revision locally, just the working tree.
[00:28] <mzz> so a lightweight checkout whose branch is remote will be awkwardly slow for some common operations.
[00:28] <RAOF> This is true.
[00:28] <mzz> of course you may prefer that over a full branch anyway.
[00:30] <hicham> i don't want any revision
[00:30] <hicham> i just want to do a simple checkout !
[00:30] <hicham> should i be forced to pull 100Mb for 5Mb of sources ?
[00:43] <mzz> hicham: then see what RAOF said
[00:43] <hicham> mzz : thanks
[00:43]  * mzz thinks he didn't describe the difference between svn checkouts and bzr lightweight checkouts correctly
[00:44] <mzz> hicham: what I meant is that with a lightweight checkout things like "bzr diff" (to compare the working tree to the current revision) go over the network
[00:44] <mzz> (that is: if they're a checkout of a branch on the network)
[00:45] <mzz> so you do have the source code locally, it's just that pretty much all bzr operations that need already-checked-in data access the network (that's slightly different from svn, which keeps a local copy of just the current revision)
[00:46] <abadger1999> Question, is bzrlib/patches.py supposed to deal with any patch or only patches created by bzr?
=== nailuj24_ is now known as nailuj24
[01:14] <jml> I'm thinking of writing a plugin command called "bzr better"
[01:15] <jml> it will tell you if your change makes the code better or not
[01:15] <jml> using a simple algorithm.
[01:15] <nailuj24> lol, how can machines find out something like this? i'm interested.
[01:16] <jml> if the diff deletes more lines than it adds, it is better.
[01:17] <nailuj24> well, that may not be very accurate, but okay for projects who've already been around for a while
[01:21] <Peng> jml: Check if it's adding or removing XXX/TODO comments. :D
[01:21] <Peng> jml: And the presence of the words "ugly" and "hack".
[01:22] <Peng> jml: Alternately, have it send the diff to Amazon Mturk.
[01:22] <jml> Peng: no, I think simple is good. Besides, I already have a plugin that checks for XXX / TODO comments in diffs.
[01:23] <Kilroo> I think I've figured out the way I can get the most benefit from using bzr with the screwball svn repositories I deal with at work until I have time to insist on getting them fixed.
[01:23] <jml> which I can't find on Launchpad :(
[01:23] <Kilroo> Assuming I can manage to get it set up right.
[01:25] <Kilroo> Shared no-trees repo per project, with one branch bound to the subversion repo and local feature branches as I feel like making them, and a lightweight checkout in my actual Eclipse workspace that I switch between branches to accomplish things.
[01:27] <Kilroo> And I think I might be figuring out a way to do something fairly similar for the projects that are still on bare ftp by having an rsync for pulling down other people's changes.
[01:28] <Kilroo> Then maybe when I try to explain what the heck I'm doing they'll get confused and I can tell them well it would be a lot simpler if we'd actually use real version control in a sensible way...
=== nailuj24_ is now known as nailuj24
[01:32] <Kilroo> Oh yes...and of course, for the projects that have them, I'll need one branch bound to the production subversion repo and one bound to the development repo.
[01:33] <mac9416> How do I revert my branch to a previous revision?
[01:35] <Kilroo> um...bzr revert -r<revision>, ain't it?
[01:36] <mac9416> I don't think so. Doesn't that revert changes since the last commit?
[01:36] <Kilroo> Correction, I think that'll undo the revision specified, so it'd be <revision+1> if revision is what you're aiming for...
[01:37] <Kilroo> http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/revert-help.html
[01:38] <mac9416> Thanks. Think I've got it now.
=== Adys_ is now known as Adys
[02:41] <mkanat> Hey mwhudson. Got your email.
[02:44] <mobodo> Hi, I'm trying to write a scrip that can be run from a web page that lets me download a bzr branch as a tgz file - is it possible to bzr branch directly to a tar file?
[02:44] <mobodo> (I'm guessing not, but I'm asking just in case)
[03:08] <mkanat> losa ping
[03:20] <mobodo> is there a bzr release command that can remove the .bzr folders?
[03:22] <Peng> mobodo: Do you want "bzr export" here?
[03:22] <RAOF> bzr export is probably what you're after.
[03:22] <Peng> Jinx!
[03:25] <jml> mkanat, you're unlikely to find a losa now.
[03:26] <mkanat> jml: Okay.
[03:26] <jml> mkanat, they've got 6x24 coverage.
[03:26] <mkanat> I just need a backtrace from loggerhead next time it freezes.
[03:26] <mkanat> (Before it's restarted.)
[03:26] <jml> mkanat, ahh right, like the bug report says?
[03:27] <mkanat> jml: Yeah, I added the note to the bug report, so I think it should be OK.
[03:27] <jml> mkanat, I reckon that mwhudson can arrange that w/ spm when they are both in on Monday
[03:27] <mkanat> jml: Okay.
[03:27] <jml> Peng: lp:difftodo is my thing for getting the XXX comments, btw,
[03:33] <Peng> jml: Oh, neat.
[03:34] <jml> Peng: if you use emacs, it's even more handy, since it makes XXXs look like compile errors so you can easily jump to them.
[03:35] <Peng> I do not use emacs. :P
[03:35] <Peng> Nano is about as much as I can handle.
[03:35] <jml> hmmm. how do I get the bzr nick of a branch via the api...
[03:35]  * jml does builtins
[03:35] <jml> branch.nick, yay
[03:36] <Peng> Be careful when getting the nick. For example, in a lightweight checkout, do you want it to check the branch, even if it's remote?
[03:37] <jml> Peng: in this context, the circumstances are very, very tightly controlled
=== Sam__ is now known as SamB_XP
[04:54] <mobodo> bzr export is exactly what I needed :)
[04:55] <mobodo> is there a way to export to stdout?
[04:56] <mobodo> got it, n/m
=== verterok_ is now known as verterok
[15:04] <grettke> Hi folks, question... I've got a shared repo that is served up over bzr. I would like to rename a project within it. Can I just rename the folder, or, is it more than that?
=== khmarbaise_ is now known as khmarbaise
[15:11] <ronny> grettke: should be enough
[15:12] <grettke> ronny: thanks I will test it out...
[16:23] <keithy> I want to have a project, but within that project there are some very large files, so I would like them to branch, only with the latest version, without the history. Is that possible?
[16:45] <maxb> keithy: If you literally want to drop all history, why not simply import the content into a new empty branch
[16:49] <nailuj24> keithy: you can bzr checkout --lightweight
[16:49] <nailuj24> this will only get the latest revision, i think
[16:59] <keithy> nailuj24: hi... I know about lightweight, however, I want to a) branch and b) only mark 2 files for "lightweight" treatment
[17:00] <nailuj24> hmm, tricky, i'm not sure whether this is possible
[17:02] <gerard_> keithy: do these large files change often?
[17:20] <keithy> yes
[17:20] <keithy> the large file is the build product of the small files
[17:21] <keithy> so you want to supply the starting point to the user
[17:21] <keithy> but not every single starting point ever
[17:31] <maxb> keithy: That sort of file should not be version-controlled at all
[18:04] <keithy> maxb but it has to be
[18:04] <keithy> because
[18:05] <keithy> you start with the starting point and build on it
[18:05] <keithy> every so often you save a new waypoint
[18:05] <keithy> the user only needs the most recent waypoint
[18:06] <keithy> if you dont version the waypoints then the builds dont work, because things get out of sync
[18:17] <Glenjamin> if its the build product of the small files, cant you just build it from them?
[18:37] <maxb> keithy: um, the build requires the output of a previous build?! How painful
[18:53] <lifeless> vila: hihi
[18:54] <vila> lifeless: reading your answer :-) I agree, I hit reply too fast.
[18:54] <vila> s/patch_attribute/restore_attribute/
[18:54] <lifeless> well yes
[18:54] <vila> but other wise I see you point
[18:55] <vila> also, that doesn't address several cases (but addAttrCleanup either):
[18:55] <vila>         def restoreDefaults():
[18:55] <vila>             msgeditor.hooks['commit_message_template'] = []
[18:56] <vila> or anything else like that where you want to restore only part of an object
[18:57] <lifeless> right
[18:57] <lifeless> but again it still isn't either part of executing a test, or of making an assertion
[18:57] <vila> It also means that we now do: addCleanup(restore_attribute()) ; set new value
[18:57] <lifeless> so I don't think it should be put on TestCase
[18:59] <vila> practicality beats purity ? I was thinking about TestCase.overrides(obj, attr_name, new_value) and makes it handle objects, lists and dicts
[18:59] <vila> even less pure :)
[19:00] <lifeless> practical only gets to claim that when it might be nicer to use
[19:00] <lifeless> if you give patch_attribute a new attribute value it could set the attribute at the time
[19:00] <lifeless> but I think that
[19:01] <lifeless> self.addCleanup(restore_attribute(...))
[19:01] <vila> lifeless: I'm deploying it on the bzr code base to see, 80% done, that removes a lot of code
[19:01] <lifeless> thing.value = new_value
[19:01] <vila> yup
[19:01] <lifeless> would be clearer to read
[19:01] <vila> yeah, may be
[19:02] <vila> and we can add restore_dict_item
[19:02] <lifeless> anyhow, you don't need to restore hooks :P
[19:02] <lifeless> It would be good to stop changing global state quite so much.
[19:02] <vila> true, I may address that in a different commit (hooks)
[19:03] <lifeless> vila: I don't know what you mean by that
[19:03] <vila> and changing global state, yeah, but that's out of scope here :)
[19:03] <lifeless> hooks are already globally reset by the test framework
[19:03] <vila> yeah
[19:04] <lifeless> by restoring the entire hooks object, not individual lists
[19:04] <lifeless> IIRC
[19:04] <vila> I may address: 'stop restoring hooks because it's useless' in another commit different than the one where I deploy addAttrCleanup/restore_attribute
[19:04] <lifeless> ok
[19:05] <lifeless> where are we manually restoring hooks?
[19:06] <vila> search for restoreDefaults, I think I've seen 2 occurrences so far
[19:07] <vila> most probably it predates the test framework handling
[19:08] <SamB_XP> just make sure you don't get any commits with messages like "silly commit" somehow ;-P
[19:09] <luke-jr> everyone should "affects me too" on https://bugs.launchpad.net/bzr/+bug/67174 plz :P
[19:09] <ubottu> Ubuntu bug 67174 in bzr "[master] record cherry-pick merges" [Medium,Confirmed]
[19:10] <lifeless> hmm added by jelmer in april 2008
[19:10] <lifeless> must have missed it when adding hook restoration/didn't review it myself or something.
[19:10] <vila> lifeless: no big deal :D
[19:22] <gerard_> "Subversion supports this now :)"
[19:22] <gerard_> now just the distributed vcs part...
[19:27] <luke-jr> heh
[19:28] <luke-jr> tbh, I think most projects only use Bazzar over Subversion for the merging capabilities ;)
[19:45] <gerard_> pfff... this merge stuff is complicated
[19:45] <gerard_> is there a document somewhere about what bazaar does internally
[19:46] <gerard_> it's not much code, but its hard to see what is going on
[20:14] <vila> lifeless: mwhahahaha bzrlib/plugins/launchpad/test_lp_api.py TestDependencyManagement.patch(self, obj, name, value)
[20:17] <Glenjamin> i dont get it?
[20:18] <gerard_> pretty ingenious
[20:18] <Glenjamin> thats just stubbing a method surely
[20:19] <vila> Glenjamin: read the logs, we discussed an alternate way to do that with lifeless a couple of minutes ago, it's fun to find an existing implementation :D
[20:19] <Glenjamin> are there any mocking frameworks?
[20:19] <Glenjamin> i know ruby has 2 or 3 gems which provide easy ways to do mocking
[20:19] <vila> Glenjamin: search bzrlib/tests
[20:19] <Glenjamin> and stubs
[20:20] <vila> Glenjamin: or have a look at lp:testtools, lp:subunit, lp:testscenarios or ask lifeless and jml for more :)
[20:37] <gerard_> could I have some comments on http://launchpadlibrarian.net/38202975/prevent_merges.patch for bug #113809 ?
[20:37] <ubottu> Launchpad bug 113809 in bzr "update performs two merges" [High,Confirmed] https://launchpad.net/bugs/113809
=== arjenAU2 is now known as arjenAU
[20:38] <vila> gerard_: I'm leaving so I can't comment right now, but do a merge proposal instead of adding a patch to a bug, you'll get more feedback sooner (instead of eventually no feedback at all)
[20:38] <gerard_> hmm ok
[20:38] <gerard_> but I know it's not good enough for a merge right now
[20:39] <gerard_> should I still do a merge proposal then?
[20:39] <vila> I'm pretty sure the process is documented in doc/developers/HACKING.txt, if not, file a bug :)
[20:39] <vila> gerard_: oh yes, no problem with that, just say so in your cover letter
[20:39]  * vila really off now
[20:39] <gerard_> ok, bye
[20:45] <lifeless> Glenjamin: yes, there are mocking libraries for python
[21:40] <timClicks> what is the easiest way to move to "checkout --lightweight" to a full-blown branch?
[21:41] <timClicks> i just want to commit locally then push to my new branch on lp
[21:59] <mzz> timClicks: you probably want "bzr help reconfigure"
[22:00] <timClicks> mzz: thanks
[23:45] <yacoob> aaargh.
[23:45] <yacoob> does bzr has any problems with smbfs?
[23:45] <yacoob> bzr: ERROR: Could not acquire lock "/Volumes/archiwum/bzr/go/.bzr/checkout/dirstate": (45, 'Operation not supported')
[23:48] <yacoob> funnily enough, I didn't have this kind of problem with previous versions of bzr