| hicham | anybody in here ? | 00:02 |
|---|---|---|
| nailuj24 | nah | 00:03 |
| hicham | how can i reduce the revision size when checking out a repo ? | 00:04 |
| hicham | any hint nailuj24 ? | 00:04 |
| nailuj24 | hmm, i don't know, but someone in here probably does | 00:06 |
| nailuj24 | let's just wait a little :) | 00:06 |
| methods | can i push to a checkout and have it instantly cause the checkout to update ? | 00:08 |
| hicham | if bzr forces everybody to download the whole history then that is just weird | 00:09 |
| nailuj24 | hicham: it's the way most dcms' work | 00:10 |
| 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:11 |
| nailuj24 | i'm sure this is possible somehow | 00:12 |
| hicham | i don't know why canonical is duplicating efforts | 00:13 |
| hicham | they created bazaar to make our life more complicated | 00:14 |
| nailuj24 | lol | 00:14 |
| 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:15 |
| 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:16 |
| nailuj24 | bzr was 1 month earlier | 00:17 |
| mzz | 1 month? that doesn't sound right | 00:17 |
| * mzz checks | 00:17 | |
| * 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:18 |
| hicham | i get more than 100Mb for 5Mb of sources ! | 00:19 |
| mzz | mmm, git's older than I thought then. | 00:19 |
| 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:21 |
| nailuj24 | hicham: well, if the new solution is better than the original one | 00:23 |
| hicham | nailuj24 : i don't know, they develop solutions for internal use only | 00:24 |
| hicham | nailuj24 : not like redhat | 00:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:43 | |
| 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:44 |
| 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:45 |
| abadger1999 | Question, is bzrlib/patches.py supposed to deal with any patch or only patches created by bzr? | 00:46 |
| === nailuj24_ is now known as nailuj24 | ||
| jml | I'm thinking of writing a plugin command called "bzr better" | 01:14 |
| 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:15 |
| jml | if the diff deletes more lines than it adds, it is better. | 01:16 |
| nailuj24 | well, that may not be very accurate, but okay for projects who've already been around for a while | 01:17 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:25 |
| 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:27 |
| 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... | 01:28 |
| === nailuj24_ is now known as nailuj24 | ||
| 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:32 |
| mac9416 | How do I revert my branch to a previous revision? | 01:33 |
| Kilroo | um...bzr revert -r<revision>, ain't it? | 01:35 |
| 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:36 |
| Kilroo | http://doc.bazaar.canonical.com/bzr.dev/en/user-reference/revert-help.html | 01:37 |
| mac9416 | Thanks. Think I've got it now. | 01:38 |
| === Adys_ is now known as Adys | ||
| mkanat | Hey mwhudson. Got your email. | 02:41 |
| 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) | 02:44 |
| mkanat | losa ping | 03:08 |
| mobodo | is there a bzr release command that can remove the .bzr folders? | 03:20 |
| Peng | mobodo: Do you want "bzr export" here? | 03:22 |
| RAOF | bzr export is probably what you're after. | 03:22 |
| Peng | Jinx! | 03:22 |
| jml | mkanat, you're unlikely to find a losa now. | 03:25 |
| 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:26 |
| 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:27 |
| Peng | jml: Oh, neat. | 03:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| jml | Peng: in this context, the circumstances are very, very tightly controlled | 03:37 |
| === Sam__ is now known as SamB_XP | ||
| mobodo | bzr export is exactly what I needed :) | 04:54 |
| mobodo | is there a way to export to stdout? | 04:55 |
| mobodo | got it, n/m | 04:56 |
| === verterok_ is now known as verterok | ||
| 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? | 15:04 |
| === khmarbaise_ is now known as khmarbaise | ||
| ronny | grettke: should be enough | 15:11 |
| grettke | ronny: thanks I will test it out... | 15:12 |
| 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:23 |
| maxb | keithy: If you literally want to drop all history, why not simply import the content into a new empty branch | 16:45 |
| nailuj24 | keithy: you can bzr checkout --lightweight | 16:49 |
| nailuj24 | this will only get the latest revision, i think | 16:49 |
| keithy | nailuj24: hi... I know about lightweight, however, I want to a) branch and b) only mark 2 files for "lightweight" treatment | 16:59 |
| nailuj24 | hmm, tricky, i'm not sure whether this is possible | 17:00 |
| gerard_ | keithy: do these large files change often? | 17:02 |
| keithy | yes | 17:20 |
| keithy | the large file is the build product of the small files | 17:20 |
| keithy | so you want to supply the starting point to the user | 17:21 |
| keithy | but not every single starting point ever | 17:21 |
| maxb | keithy: That sort of file should not be version-controlled at all | 17:31 |
| keithy | maxb but it has to be | 18:04 |
| keithy | because | 18:04 |
| 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:05 |
| keithy | if you dont version the waypoints then the builds dont work, because things get out of sync | 18:06 |
| Glenjamin | if its the build product of the small files, cant you just build it from them? | 18:17 |
| maxb | keithy: um, the build requires the output of a previous build?! How painful | 18:37 |
| lifeless | vila: hihi | 18:53 |
| 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:54 |
| 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:55 |
| vila | or anything else like that where you want to restore only part of an object | 18:56 |
| 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:57 |
| 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 :) | 18:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| lifeless | where are we manually restoring hooks? | 19:05 |
| vila | search for restoreDefaults, I think I've seen 2 occurrences so far | 19:06 |
| vila | most probably it predates the test framework handling | 19:07 |
| SamB_XP | just make sure you don't get any commits with messages like "silly commit" somehow ;-P | 19:08 |
| 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:09 |
| 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:10 |
| gerard_ | "Subversion supports this now :)" | 19:22 |
| gerard_ | now just the distributed vcs part... | 19:22 |
| luke-jr | heh | 19:27 |
| luke-jr | tbh, I think most projects only use Bazzar over Subversion for the merging capabilities ;) | 19:28 |
| gerard_ | pfff... this merge stuff is complicated | 19:45 |
| gerard_ | is there a document somewhere about what bazaar does internally | 19:45 |
| gerard_ | it's not much code, but its hard to see what is going on | 19:46 |
| vila | lifeless: mwhahahaha bzrlib/plugins/launchpad/test_lp_api.py TestDependencyManagement.patch(self, obj, name, value) | 20:14 |
| Glenjamin | i dont get it? | 20:17 |
| gerard_ | pretty ingenious | 20:18 |
| Glenjamin | thats just stubbing a method surely | 20:18 |
| 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:19 |
| vila | Glenjamin: or have a look at lp:testtools, lp:subunit, lp:testscenarios or ask lifeless and jml for more :) | 20:20 |
| 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 | 20:37 |
| === arjenAU2 is now known as arjenAU | ||
| 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:38 |
| 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:39 |
| lifeless | Glenjamin: yes, there are mocking libraries for python | 20:45 |
| timClicks | what is the easiest way to move to "checkout --lightweight" to a full-blown branch? | 21:40 |
| timClicks | i just want to commit locally then push to my new branch on lp | 21:41 |
| mzz | timClicks: you probably want "bzr help reconfigure" | 21:59 |
| timClicks | mzz: thanks | 22:00 |
| 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:45 |
| yacoob | funnily enough, I didn't have this kind of problem with previous versions of bzr | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!