| mkanat | <dwm> we're going through The Great DVCS Debate (Summer 2010 Edition) now, I have noticed the bazaar/subversion integration is way ahead of other DVCS offerings | 00:18 |
|---|---|---|
| mkanat | ^^^^^^^^^^ That's Yahoo. | 00:18 |
| GungaDin | in revisionspec, does 'ancestor' relate to any common revision? or a common branch? | 02:34 |
| wgrant | GungaDin: Common revision. | 04:19 |
| GungaDin | thx | 04:27 |
| === lifeless_ is now known as lifeless | ||
| mtaylor | gah | 07:28 |
| mtaylor | $ bzr push --no-stacked lp:~ozone-core/ozone/devel | 07:28 |
| mtaylor | Using default stacking branch /~ozone-core/ozone/spm-test at lp-70455952:///~ozone-core/ozone | 07:28 |
| mtaylor | FAIL | 07:28 |
| spm | argh | 07:28 |
| mtaylor | um. o hai --no-stacked | 07:28 |
| parthm | hello. is 2.2b4 feature freeze or is it 2.2rc1? ... i am asking in the context of any new merge proposals. | 08:03 |
| vila | parthm: AIUI the feature freeze is already in effect | 08:19 |
| parthm | vila: ok. thanks. so the trunk is for 2.3 now? | 08:20 |
| === parthm_ is now known as parthm | ||
| vila | parthm: ha, the tricky one :) I'd say no, but you should ask the RM ! | 08:38 |
| jam | parthm: 2.2b4 isn't a strict feature freeze, but it *is* an api freeze | 08:39 |
| jam | so that plugins can stabilize for the 2.2rc1 in a month | 08:39 |
| jam | however, if we need to, we can split 2.2 off | 08:40 |
| jam | I'll ask poolie what he thinks | 08:40 |
| jam | we certainly want to avoid waiting on landing code | 08:40 |
| jam | parthm: poolie finalizes, trunk is now 2.3 | 08:40 |
| jam | I'll submit a patche | 08:40 |
| jam | patch | 08:40 |
| parthm | jam: ok. thanks for clarifying. one more question. should patches be submitted against trunk and proposed against 2.2 on a case by case basis? or (if they don't break api) they should be proposed against 2.2 branch and merged into trunk for now? | 08:42 |
| parthm | looks like i may need to rework the news entry for https://code.launchpad.net/~parthm/bzr/603461-ensure-no-var-named-message/+merge/29624 :P and propose it again. | 08:44 |
| poolie | parthm, jam, yes, features that don't break apis and aren't too risky are welcome | 08:45 |
| jam | parthm: if you think it is safe for 2.2, propose it there | 08:45 |
| jam | 2.x is always merged up into trunk | 08:46 |
| jam | so it saves having multiple proposals | 08:46 |
| parthm | poolie, jam: ok. i will do that. thanks. | 08:46 |
| === Meths_ is now known as Meths | ||
| === CardinalFang_ is now known as CardinalFang | ||
| === Cardinal` is now known as CardinalFang | ||
| === beuno is now known as beuno-lunch | ||
| JoshBrown | I'm working with Bazaar on Launchpad and was wondering how the branch, change, commit, merge process goes? Currently I am pulling from the branch, working on it, then pushing it back, is this 'best practice'? | 17:14 |
| rubbs | JoshBrown: that is one way of doing it. There is no one right way to do it, but what I tend to do is pull one down and have it as my "mirror" of the LP branch. then I branch from my local one and hack away. When I want to get it into lp I push/merge to the local one and push up to LP. | 17:16 |
| rubbs | the reason i do this is if I want two or more branches from the same lp branch | 17:16 |
| rubbs | it also allows for the mirror to keep up to date in case your work is taking a while. | 17:18 |
| rubbs | but others here might offer a different workflow | 17:18 |
| JoshBrown | rubbs: Great, I finally did something right! :) | 17:18 |
| JoshBrown | rubbs: For some reason I thought that maybe merges were supposed to be done on the Launchpad end. | 17:19 |
| rubbs | JoshBrown: usually not. Merges are easier to do locally and then push to lp | 17:19 |
| rubbs | JoshBrown: the mirror approach also keeps all your history in line with the LP branch rather than jumping back and forth between branches | 17:20 |
| rubbs | JoshBrown: in other words, the mirror/LP history is always on the left (first one seen) and the working branches are on the right (seen after you expand this history at the merges) | 17:20 |
| JoshBrown | rubbs: Yeah, I'm glad you can merge locally for ease of use / keeping in sync. It's just the fact that merge /proposals/ are done on Launchpad that threw me off. | 17:22 |
| rubbs | JoshBrown: well merge proposals are slightly different. | 17:23 |
| rubbs | JoshBrown: LP's MPs are for branches you don't have commit access too. So you can clone/branch from them, but you won't be able to push to it. | 17:23 |
| rubbs | in this case you submit a proposal and have a link to your branch and someone with commit access can merge it in for you (provided they accept it) | 17:24 |
| JoshBrown | rubbs: Ah, so if you have access to the branch you don't bother with a merge proposal? Got it. | 17:25 |
| rubbs | JoshBrown: you don't have to IIRC, but it may be good practice if you wish to have a process in place | 17:25 |
| rubbs | http://doc.bazaar.canonical.com/bzr.2.1/en/tutorials/using_bazaar_with_launchpad.html | 17:26 |
| JoshBrown | Thanks. | 17:27 |
| rubbs | np | 17:29 |
| === beuno-lunch is now known as beuno | ||
| Meths | If you run bzr uncommit on a tree are the bzr pull references it gives you good for the life of the tree or can doing the wrong thing break those? | 18:50 |
| Meths | It think my real question is can you run bzr revert after doing uncommit so you have a completely clean revision and then apply those pull commands? | 18:50 |
| poolie | they will last within that repostiroy | 18:51 |
| poolie | Meths, why would you want to do that? | 18:51 |
| Meths | For some reason one of our devs had content conflicts doing a bzr update on their version of trunk. They ran uncommit forgetting it would affect the lp copy but whatever caused the conflicts (which didn't show up on lp or others trees) shows in their bzr st | 18:53 |
| Meths | So could they just revert so that they have a clean bzr st then run the bzr pull commands to reapply the uncommits and see if that cleans it up? | 18:54 |
| poolie | right | 18:56 |
| poolie | if they didn't like the conflicts they probably should have just reverted, i think | 18:56 |
| Meths | Possibly, it still isn't clear how you can get content conflicts just running bzr update every so often on a checkout from lp so not sure what they could have done to their copy. | 18:58 |
| poolie | when you update, it merges the upstream changes against your uncommitted changes | 18:59 |
| Meths | poolie: Exactly, normally our workflow means you wouldn't make any changes directly in the trunk checkout. I'll ask them if they may have done. In the meantime we'll do the bzr revert to get it clean and run the pulls. | 19:01 |
| poolie | k | 19:02 |
| poolie | just for curiousity, which project? | 19:02 |
| Meths | openlp | 19:03 |
| Meths | poolie: will those pull references be in a fresh checkout from lp? | 19:04 |
| maxb | Meths: I believe they will _not_ because they won't be in the ancestry of the branch head. However, a subsequent attempt to refer to them might pull them from the lp branch at that time | 19:17 |
| Meths | maxb: Thanks. They seemed to be though and all is fixed now. I assume as the uncommit happened on the lp copy as well, the references were also stored there. | 19:19 |
| [reed] | does bzr support pulling a repo within a repo? as in, I have a top level "server" repo, but within that repo, I want the "extensions" directory to pull from another repo (similar to svn:externals) | 19:35 |
| [reed] | as the extensions apply to more than just this one server | 19:35 |
| [reed] | ooo | 19:38 |
| [reed] | https://edge.launchpad.net/bzr-externals | 19:38 |
| bbutz | it is possible to cherry pick multiple files when merging? I have an intermediate branch, and want to merge files that are across multiple revisions of another branch into it | 20:04 |
| === mm-mysql is now known as mark|autoconnect | ||
| === Adys_ is now known as Adys | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!