| wkharold | test | 00:30 |
|---|---|---|
| josh_k | is it possible to bzr branch a subdirectory of a project? | 00:45 |
| Peng | josh_k: Not really. | 00:54 |
| josh_k | Peng yeah | 00:54 |
| josh_k | figuring out I need to make separate branches | 00:55 |
| === maxb changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: vila | bzr 2.1.0rc2 and 2.0.4 have gone gold | ||
| maxb | Has a date been set for 2.1.0 final? | 01:04 |
| === khmarbaise_ is now known as khmarbaise | ||
| fbond | TEST | 03:37 |
| fbond | Disregard, etc. | 03:37 |
| vish | guys the latest bzr update broke dependencies for bzr-gtk | 10:49 |
| Peng | bzr update where? The PPA? | 10:50 |
| Peng | (Not that I can help, but I'm curious, at least.) | 10:50 |
| vish | "bzr-gtk: Depends: bzr (< 2.1~) but 2.1.0~rc2-1 is installed." | 10:51 |
| vish | Peng: there is a ppa? | 10:51 |
| Peng | https://launchpad.net/~bzr/+archive/ppa and a couple others (~bzr-beta-ppa and a nightly one), but you shouldn't expect the dependencies to be perfect there, either. | 10:52 |
| vish | hmm , there is no bzr-gtk for Lucid :( bzr update was uploaded by james_w or maxb .. | 10:54 |
| maxb | Huh? I don't have access to bzr PPAs | 11:08 |
| vish | maxb: nah , the Lucid update , it mentioned your name :) | 11:09 |
| maxb | um, really!? | 11:10 |
| vish | maxb: i think it was wrt something about untangling the bzr-tools | 11:10 |
| maxb | That was bzr-builddeb | 11:11 |
| vish | ah right ... | 11:11 |
| vish | maybe the bzr-gtk needs to bump dependencies | 11:11 |
| vish | anyone know how to force a package to install? | 11:12 |
| vish | ignore dependencies rather | 11:12 |
| maxb | It's not worth it, you'll end up with a permanently upset apt until you fix the dependency issue | 11:12 |
| vish | maxb: yeah , i wanted to mainly check if the -gtk worked with the new bzr [or i'm just being plain crazy ;) ] | 11:13 |
| vish | it was just an idea :) | 11:14 |
| maxb | Just bzr branch it into ~/.bazaar/plugins/, much easier | 11:14 |
| vish | ah.. will give it a try | 11:16 |
| geser | Hello, is the fix for bug #515597 supposed to be included in the bzr package in lucid (2.1.0~rc2-1)? | 11:31 |
| ubottu | Launchpad bug 515597 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Critical,Fix released] https://launchpad.net/bugs/515597 | 11:31 |
| spiv | geser: I'd guess no | 11:36 |
| spiv | geser: it was fixed just after 2.1.0rc2 in upstream according to the NEWS file | 11:36 |
| geser | spiv: how to proceed? wait for the next rc or apply the change on the package in lucid? | 11:40 |
| maxb | Surely 2.1.0 final is due any day now? | 11:41 |
| spiv | geser: not sure | 11:58 |
| spiv | geser: on one hand as maxb says probably the next release will happen soon (although I don't remember the exact schedule) | 11:59 |
| spiv | geser: but if you wanted to make a 2.1.0~rc2+r4812 or something in the meantime, I don't see any harm | 12:01 |
| spiv | geser: (in addition to the fix for #515597, there are a few other fixes, of which #513432 is probably also pretty important) | 12:02 |
| geser | spiv: I don't know how much that bug affects the bzr usage but there is already a bug filed about the bzr package in lucid: bug #521546 | 12:04 |
| ubottu | Launchpad bug 521546 in bzr "TypeError: merge_text() takes exactly 2 arguments (3 given)" [Undecided,New] https://launchpad.net/bugs/521546 | 12:04 |
| spiv | geser: I haven't looked closely, but probably only affects custom merge hooks | 12:09 |
| spiv | geser: i.e. the 'news_merge' plugin that's now distributed with bzr (but not enabled by default), and the merge hook in bzr-builddeb for debian/changelog files | 12:09 |
| spiv | geser: that latter case is going to hit ubuntu devs pretty hard though | 12:09 |
| rioch | I'm about to create my first release in a project. Should I branch my code? | 14:20 |
| mathrick | rioch: that's not a bad idea, but at least tagging would be good | 14:42 |
| mathrick | something to identify unambiguously the revision you released | 14:42 |
| mathrick | branching depends on whether you intend to support the release further, or only make new releases | 14:43 |
| rioch | mathrick: well the way I see it is, I might want to fix a serious bug, without disrupting new development | 14:45 |
| rioch | and im not sure of the difference between a tag and a branch | 14:45 |
| mathrick | tag is jus a descriptive label attached to a particular revision | 14:46 |
| mathrick | so you can go back to it later and know precisely where you released | 14:46 |
| mathrick | a branch is, well, a branch, a separate line of history | 14:46 |
| mathrick | it's possible to tag now, with the expectation you might not need anything else, and branch only when you actually need to fix something | 14:47 |
| mathrick | if you tag, you won't have any problems going back to that point later on | 14:47 |
| rioch | mathrick: ok. so is that possible using launchpad? | 14:48 |
| mathrick | tagging? Sure, lpad only keeps your history, and understands tags too | 14:49 |
| mathrick | rioch: bzr help tag | 14:49 |
| mathrick | then push | 14:49 |
| mathrick | if you ever need to go back and branch, bzr branch -r tag:RELEASE_1_0 ~/project | 14:50 |
| mathrick | then you push it again to launchpad and have a new branch exactly at the point you released 1.0 | 14:50 |
| rioch | that would mean I always develop in the trunk branch, tag my releases, and then if I need to bugfix a release, I grab the related tag and create a branch out of it. | 14:52 |
| rioch | does that seem sensible/correct? | 14:52 |
| mathrick | yes, that's exactly what I proposed | 14:52 |
| rioch | it seems good to me :) | 14:52 |
| mathrick | rioch: you can mix it freely, too. For instance, pre-2.0 developer releases will only need tags, because you don't intend to support them. So you tag 1.9a1, 1.9a2, 1.9b1, 1.9rc etc, then once you have released and tagged 2.0, you can branch it because it's gonna be more persistent | 14:52 |
| rioch | so you mean branch and tag major releases? | 14:53 |
| mathrick | or something, whatever fits your project | 14:53 |
| mathrick | as long as you have them tagged, you can always go back | 14:53 |
| mathrick | the problem with DVCS isn't branching, it's accurately recreating the chronological order of events | 14:54 |
| mathrick | and that's what tags help with | 14:54 |
| rioch | So tagging is important. Got it. :) | 14:54 |
| mathrick | yeah, if you make formal releases, then you really want to tag | 14:55 |
| rioch | I was thinking of having a branch for each major release, and what you mentioned about tagging pre-releases seems like a smart idea, but it seems that I'd end up with a lot of branches which wouldn't be used. | 14:55 |
| mathrick | it's pretty embarassing to go back to a release two months later and be unable to identify which revision you released it from | 14:55 |
| mathrick | rioch: that's why you only tag them. Tags by themselves don't do anything, they just stick to a revision and can be read | 14:56 |
| mathrick | so you keep your history linear when possible, and only go back and branch to releases you actually need to support | 14:56 |
| mathrick | prereleases are obviously not supposed to be supported, so nothing more is needed | 14:57 |
| rioch | I think I will do that. I suppose the confusion for me is trying to align it with launchpad. I want to release a beta version, but there is no separate branch for it, so I tag it... | 14:57 |
| mathrick | yes, and launchpad understands tags, so it'll show you that they exist | 14:58 |
| rioch | So at the moment, I've set a milestone to released and uploaded the files for download. Now I can just go and tag it and it's done? | 14:58 |
| mathrick | yup | 14:58 |
| mathrick | just push to lpad afterwards to have it receive the tag you created | 14:58 |
| rioch | here goes :s | 14:59 |
| rioch | How can I check if it worked? bzr said: no new revisions to push. | 15:01 |
| mathrick | rioch: bzr log lpad:myproject | 15:03 |
| mathrick | it should have Tags: RELEASE_1_0 or whatever you called it next to the revision you tagged | 15:03 |
| rioch | hmmm nothing there | 15:05 |
| rioch | All I did was bzr tag pumped-0.1 and then bzr push lp:pumped | 15:05 |
| rioch | was that correct? | 15:05 |
| mathrick | yes | 15:07 |
| rioch | if I do bzr tags, I can see it listed for revision 17 (latest revision) | 15:07 |
| rioch | let me see if I can get the tag | 15:07 |
| mathrick | ------------------------------------------------------------ | 15:07 |
| mathrick | revno: 17 | 15:07 |
| mathrick | tags: pumped-0.1 | 15:07 |
| mathrick | committer: Jon Black (jon@pumped.nl) | 15:07 |
| mathrick | branch nick: pumped | 15:07 |
| mathrick | timestamp: Sun 2010-02-14 13:10:12 +0100 | 15:07 |
| mathrick | message: | 15:07 |
| mathrick | fixed setup.py to copy glade files | 15:07 |
| mathrick | oops, sorry for pasting | 15:07 |
| mathrick | still | 15:07 |
| mathrick | rioch: it's usually a good idea to make a commit just for the release, stating that in the commit message, and attach the tag to it | 15:08 |
| mathrick | it's a bit easier to read this way | 15:08 |
| rioch | yeah, I think I'll do that next time. | 15:08 |
| rioch | but it worked, so I'm happy. | 15:08 |
| rioch | This means I can carry on coding and always get that version back from bzr, and if I need to, create a branch from it? | 15:09 |
| mathrick | yup | 15:09 |
| rioch | great. thank you so much for helping. | 15:11 |
| mathrick | you're welcome | 15:11 |
| rioch | another question, more launchpad related. Can two series point to the same branch? | 15:14 |
| mathrick | no idea | 15:15 |
| mathrick | rioch: oh, and regarding the workflow, if you find yourself going back and branching more than you expected, you might want to reverse the workflow and start branching eagerly, and then splitting clearly bufgixing work from development | 15:17 |
| mathrick | with bugfixing happening on release branches and then being backported to trunk | 15:17 |
| mathrick | this way you'll avoid headaches when you commit a bugfix to trunk, and then can't pull it to release branch because it doesn't have the preceding commit | 15:18 |
| mathrick | in fact, doing bugfixes on branches first is a good idea in general for precisely this reason | 15:18 |
| rioch | meaning I should always branch first before fixing | 15:19 |
| rioch | I think I will only ever need to branch when the bug is so important that it can't wait for the next release. | 15:19 |
| rioch | I don't expect that to be very often. | 15:20 |
| mathrick | yes, and work on the branch first. So if you find a bug in pumped-0.1, you go: bzr branch -r tag:pumped-0.1, then go to the branch, fix it there, and only then merge trunk with the branch | 15:20 |
| mathrick | rioch: fair enough | 15:20 |
| mathrick | just remember doing it in this order will give you cleaner merges without the need for cherrypicking | 15:20 |
| rioch | when you say "go to the branch", you mean the newly created branch for that bug fix | 15:21 |
| mathrick | well, newly created branch for pumped-0.1 | 15:21 |
| rioch | yeah | 15:21 |
| mathrick | if you find another one, you don't need to branch again, you just fix it there | 15:21 |
| mathrick | and backport (well, forward-port) to trunk again | 15:21 |
| rioch | I'm not looking forward to doing this in practice :) | 15:21 |
| rioch | I think I'll save this chat for reference. lol. | 15:21 |
| mathrick | nah, it's pretty trivial once you have a clear mental picture of how it works | 15:22 |
| mathrick | it's just understanding how the history graphs behave | 15:22 |
| mathrick | bzr operates on tree states as the fundamental items, so all patches necessarily depend on everything before them | 15:23 |
| mathrick | darcs for instance doesn't, having patches as the fundamental unit, so there branches just happen incidentally and you'll usually be able to move an unrelated bugfix easily if it didn't touch the parts that have changed | 15:23 |
| mathrick | but darcs has a horrible UI | 15:24 |
| rioch | getting that mental picture is the part that makes me nervous. | 15:26 |
| mathrick | btw, bzr people here: how difficult would it be to create something similar on top of bzr? http://github.com/droundy/iolaus | 15:26 |
| mathrick | rioch: it's just practice | 15:26 |
| === radoe_ is now known as radoe | ||
| gerard_ | praise to everyone who made bzr-svn possible | 19:24 |
| gerard_ | it's wonderful! :) | 19:24 |
| goundy | gerard_, lol you're right I remember when I used it. it's so greate :°) | 19:30 |
| jelmer | gerard_: Thanks! | 19:40 |
| gerard_ | jelmer: you're the (main) author right? | 19:41 |
| gerard_ | really great that I could just get trunk from the launchpad mirror and then only download the extra revisions for another branch | 19:42 |
| gerard_ | it works much much better than git-svn | 19:42 |
| gerard_ | the fact that I can just push to svn... mmmm... :) | 19:43 |
| mtaylor | bzr seems to think that one of my files is a binary file... is there a way to convince it otherwise? | 20:21 |
| gerard_ | mtaylor: remove the NUL char? | 20:22 |
| mtaylor | gerard_: hrm... | 20:22 |
| maxb | bzr-svn is great, it's true. Though it suffers rather, speed-wise, when pointed at a 380k revision svn repository | 20:42 |
| gerard_ | maxb: yeah, but I think we can blame that on svn | 20:44 |
| maxb | My cache.tdb alone is 250MB | 20:44 |
| maxb | mm... it would be nice if bzr-svn could ignore the revisions not related to the project I'm operating on | 20:44 |
| === poolie changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.0final rsn | ||
| lifeless | technical term ? | 21:06 |
| === lifeless changed the topic of #bzr to: Bazaar version control | try https://answers.launchpad.net/bzr for more help | http://irclogs.ubuntu.com/ | Patch pilot: poolie | bzr 2.1.0final releasing soon! | ||
| dutchie | is there a merge algorithm that just uses the one from the tree being merged? | 21:16 |
| === davidstrauss_ is now known as davidstrauss | ||
| lifeless | dutchie: you could write a per-file hook in 2.1 to do that on selected file (or all files if you want... ) | 21:19 |
| mwhudson | jelmer: ping | 21:19 |
| dutchie | lifeless: hmm, don't think it's quite work it, when I can just move the .OTHER file on top of it | 21:20 |
| dutchie | just wondered if there was an easy built in way | 21:21 |
| lifeless | yes | 21:22 |
| poolie | dutchie: vila is likely to add that in his resolve work | 21:22 |
| lifeless | you can write a per-file merge hook in bzr 2.1 :) | 21:22 |
| poolie | i don't think it's landed yet | 21:22 |
| poolie | "easy" means something different for lifeless | 21:22 |
| poolie | :) | 21:22 |
| dutchie | I can't be bothered faffing about updating to a non-distro version when I can do it in one line with find | 21:22 |
| lifeless | poolie: I think dutchie means 'discard local changes always' not 'discard on conflicts' | 21:23 |
| lifeless | dutchie: do you mean that ? | 21:23 |
| dutchie | is there a difference? | 21:23 |
| lifeless | dutchie: a huge one | 21:23 |
| dutchie | ah yes, so there is | 21:23 |
| poolie | if you mean that then you should say | 21:23 |
| poolie | 'bzr revert -rbranch:../otherthing .' | 21:23 |
| * dutchie ponders | 21:23 | |
| poolie | after doing the merge, before committing | 21:23 |
| dutchie | I think I want a true merge, but discard local on conflicts | 21:25 |
| maxb | That seems an odd thing to want. | 21:29 |
| maxb | Either the local changes are valuable or they are not. | 21:29 |
| lifeless | I think we need a new hook to satisfy that really nicely | 21:30 |
| dutchie | I'm merging in translations from launchpad; most of them come from the remote branch I'm merging in, but some are done to the branch directly in the mainline | 21:37 |
| dutchie | I can't really resolve conflicts manually, as I don't know what the words actually mean | 21:38 |
| dutchie | so I'm just using the translation from LP | 21:38 |
| lifeless | and having poke at it it willbe a little complex to do nicely | 21:39 |
| lifeless | conflicts aren't trivially accessible mid-flight, and the built in merge doesn't use the generic conflict return value. | 21:39 |
| lifeless | thats something we can improve though | 21:40 |
| thrashold | Can anyone suggest a standard .bzrignore for autoconf projects that I can use as a basis for mine? | 22:32 |
| lifeless | there should be a decent on in lp:libcpuinfo | 22:32 |
| thrashold | Thank you very much | 22:33 |
| malibu | I'm wondering if someone can help me out... Something has gone horribly wrong with my bzr working copy... I get a memory error when I commit it and it's stuck | 23:06 |
| malibu | are there any commands I can do to kind of clear it out? | 23:06 |
| Peng | You get a MemoryError? Do you have any extremely large files? Or a ton of files? | 23:08 |
| Peng | Or are you on SunOS? | 23:08 |
| mwhudson | james_w: wow that email about branch formats DoSes thunderbird quite effectively | 23:08 |
| james_w | nice | 23:08 |
| Peng | Eek, what email? I use Thunderbird. | 23:09 |
| mathrick | how difficult would it be to create something similar on top of bzr? http://github.com/droundy/iolaus | 23:09 |
| fullermd | Peng: Only if you're on SunOS :p | 23:09 |
| mwhudson | Peng: on the udd list | 23:09 |
| mathrick | this being darcs-on-git | 23:09 |
| lifeless | mathrick: what bzr version | 23:10 |
| lifeless | Peng: its on udd | 23:10 |
| mathrick | lifeless: did you mean malibu? | 23:11 |
| lifeless | mathrick: I did, sorry. | 23:11 |
| lifeless | and to answer the question, fairly easy | 23:11 |
| lifeless | malibu: what bzr version | 23:11 |
| mathrick | and would that have a chance of working properly with everything else built with bzr? | 23:12 |
| lifeless | sure, I mean it depends on what you do ;) | 23:13 |
| lifeless | looms for example work very well with everything else, and they provide a custom branch format- they are a deepish extension to map packaging into bzr | 23:13 |
| lifeless | bbs | 23:13 |
| malibu | Peng, Define extremely large.. Largest file is about 120Mb | 23:16 |
| malibu | bzr 2.0.1 | 23:17 |
| Peng | malibu: It's not surprising that bzr would use several hundred MB of RAM, then. | 23:17 |
| malibu | Peng, really.. that sucks | 23:18 |
| lifeless | malibu: git., hg, bzr - they all do this | 23:18 |
| lifeless | 2-3 copies of the file in memory is needed to do diff/merge/etc | 23:19 |
| malibu | Yeah I went with bzr because I need lightweight | 23:19 |
| lifeless | malibu: just saying, its a limitation all the current open source DVCS tools have | 23:19 |
| malibu | right, I understand. | 23:19 |
| malibu | I'm just looking to do a dropbox kind of thing without dropbox | 23:20 |
| malibu | And bzr seems to be the only one that has a minimal local working copy size | 23:20 |
| malibu | *sigh* I guess I will look for something else | 23:21 |
| mathrick | lifeless: that sounds very nice. Honestly the incidental branches are the only thing I miss from darcs | 23:23 |
| mathrick | as I already have interactive commits | 23:23 |
| mathrick | lifeless: oh, and does "depends on what you do" also include log viewers not going bonkers when you do that? :) | 23:24 |
| bob2 | malibu: tahoe-lafs is a lot more like dropbox than a dvcs is | 23:28 |
| poolie | malibu, or you could use unison | 23:55 |
| malibu | I was just looking at a page on unison actually | 23:58 |
| malibu | I was leaning towards just using rsync + a lightweight incremental backup tool | 23:58 |
| malibu | Which maybe is kind of what unison is | 23:59 |
| malibu | bob2: tahoe-lafs.. I will look that up | 23:59 |
| malibu | bob2: Ick.. my whole intention is to avoid 'the cloud' | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!