| === wgrant_ is now known as wgrant | ||
| Noldorin | hah | 00:06 |
|---|---|---|
| Noldorin | silence... | 00:06 |
| mgrandi | heh | 00:06 |
| mgrandi | i'm still confused on how to do conflict resolution. every 'tool' ive tried sucks or does it wrong | 00:07 |
| mgrandi | might as well just edit them by hand | 00:07 |
| Noldorin | mgrandi, OS? | 00:13 |
| mgrandi | any of them, mac windows or linux | 00:13 |
| Noldorin | at the worst, use bzr resolve from the command line | 00:13 |
| Noldorin | on windows i use winmerge | 00:13 |
| Noldorin | kdiff3 is also fine on windows and linux | 00:13 |
| mgrandi | well what file should it be 'merging into' | 00:13 |
| mgrandi | is really my question | 00:14 |
| mgrandi | the one i was using was merging everything into base, and bzr doesn't like that | 00:14 |
| Noldorin | yeah, merge into the normal file | 00:15 |
| Noldorin | no extra extension that is... | 00:15 |
| mgrandi | hmm | 00:15 |
| mgrandi | cause the one i was using on mac, DiffMerge asked me for the left right and 'ancestor file' | 00:16 |
| mgrandi | and that was this other and base, and had me merge into base.. | 00:16 |
| Noldorin | http://doc.bazaar.canonical.com/beta/en/user-guide/resolving_conflicts.html | 00:18 |
| Noldorin | mgrandi, read that | 00:18 |
| Noldorin | download WinMerge and/or KDiff3 | 00:18 |
| Noldorin | they are the best tools, at least on Windows | 00:18 |
| Noldorin | and then you're sorted | 00:18 |
| Noldorin | use bzr qresolve for a GUI resolve | 00:18 |
| Noldorin | or specify via the command line | 00:18 |
| mgrandi | hmm | 00:19 |
| Noldorin | so yeah, actually you can merge "into" any of those 3 files | 00:19 |
| Noldorin | but bzr looks ofr an extensionless one at the end | 00:19 |
| Noldorin | so you either have to create a new file that is the result of the merge...or rename an old one | 00:19 |
| mgrandi | hmm | 00:19 |
| mgrandi | ok | 00:20 |
| Noldorin | brb | 00:20 |
| === spiv_ is now known as spiv | ||
| vivekimsit | I have one doubt! I did a checkout of a branch, I commit some changes locally and saw that the branch from which I did the checkout has also done some changes after my checkout. What should I do? | 06:07 |
| spiv | vivekimsit: depends on what you want to do :) | 06:34 |
| spiv | vivekimsit: you might want to use 'bzr update', and integrate both sets of changes | 06:34 |
| spiv | vivekimsit: if you want to discard your changes, or their changes, you'd do something different, etc. | 06:35 |
| vivekimsit | spiv: ok! so bzr up will integrate both the changes, no matter I have committed to my local or not! | 06:45 |
| === Ng_ is now known as Ng | ||
| mgz | morning | 08:25 |
| mgz | wonder if isp has reason for net having been down all night... | 08:25 |
| fullermd | The electrons were spun down for refueling. | 08:35 |
| === fredp` is now known as fredp | ||
| crisb | is there a hook I can use that only gets run when doing a bzr update? | 12:28 |
| jelmer | crisb: you can use the post_branch_tip_change hook, but that gets called for pull and push too | 12:29 |
| jelmer | crisb: another option is to register a command hook and in that hook check if the command being run is update | 12:29 |
| mgz | right, command hooks were added in 2.6, but you probably want one of the branch changed ones really | 12:30 |
| crisb | can i do it so that it runs before the update using pre_branch_tip_change? i'd like to bind the branch before update. | 12:33 |
| mgz | ...it might help if you go back a few steps and say what you're actually aiming at | 12:33 |
| crisb | sure, I'm doing a plugin to ensure that when someone does a bzr update they're always getting the latest stuff from the master branch, so i'd like to bind before updating, do the update and then unbind | 12:35 |
| mgz | what prompted this? people pulling from the wrong branch? | 12:38 |
| crisb | more like people doing update when unbound, finding no changes and then assuming they have the latest. | 12:38 |
| mgz | I use update quite a bit to do things between local branches, I don't want to operate on a remote branch unless I pull explicitly on a branch with a remote parent | 12:39 |
| mgz | I'd suggest instead of a hook touching update, | 12:39 |
| mgz | that if you really want to do something to fit in a funny workflow like this, you do a plugin with a new command that does whatever fancy dance you need and tell people use that instead | 12:40 |
| mgz | update does useful things not related to getting the newest code in a bound branch, changing that behaviour in a plugin is likely to break things | 12:41 |
| crisb | what makes it a funny workflow? (it's not my workflow so i'm not necessarily saying I dont think it's funny :) | 12:42 |
| mgz | if I understand correctly, people have a bound, but non-pristine, copy of a remote trunk, which is just asking for accidents | 12:43 |
| mgz | either need a bound pristine copy of trunk, which would then complain if you try and merge a feature branch onto it when it's out of date | 12:44 |
| crisb | sort of, usual workflow is they have an unbound version of a trunk, then do their work, commits la la la, then when they want to 'commit' their work to the server, they bind, update and commit the single revision, and unbind | 12:45 |
| mgz | or just a copy of trunk that `bzr pull` will update | 12:45 |
| mgz | ^right, that seems to be asking for problems to me | 12:46 |
| mgz | is this a huge project that people don't want more than one working tree of around at a time? | 12:46 |
| crisb | not massive no | 12:47 |
| crisb | they're heavyweight checkouts anyway | 12:47 |
| mgz | just seperating out the branch for hacking on from the copy of trunk would simplify things no end | 12:47 |
| crisb | you're talking about having feature branches which someone merges onto the trunk? | 12:48 |
| mgz | right, which is basically what they're doing currently, but by unbinding trunk to diverge rather than branching | 12:48 |
| crisb | ok thats how my team operates | 12:49 |
| crisb | they branch, hack, push to a dev location, i merge them in. | 12:49 |
| mgz | they can still merge onto a local bound trunk themselves when they're done | 12:49 |
| mgz | but with a merge between the two local branches operation, rather than bind/update | 12:50 |
| crisb | this would avoid losing the history of their local commits too wouldnt it | 12:50 |
| mgz | the history is always there, log just shows the mainline only by default | 12:51 |
| crisb | sorry i mean if you bind to a trunk all your local updates become uncommitted and the history lost right? | 12:51 |
| mgz | hm, I'm not totally sure what happens in that case as I've never tried binding a diverged branch, but it's something like that | 12:52 |
| crisb | ok so you're saying have two copies of the branch, one bound, one unbound. hack on the unbound one then merge using the bound one | 12:53 |
| mgz | okay, so the effect is the same as the merging would be, your local commits get moved to a pending merge on the right hand side | 12:55 |
| mgz | crisb: right, that's simpler to get right I think | 12:56 |
| mgz | and when something goes wrong, it's easier to fix it too | 12:56 |
| crisb | how so? | 12:57 |
| mgz | the bind/update thing makes it hard to recover your local state if you can't commit | 12:57 |
| crisb | hmm why wouldnt you be able to commit? | 12:59 |
| spiv | Especially as update will default to attempting a merge even when you have uncommitted changes, whereas merge will stop (and require you to use --force if you really want to risk making that sort of mess) | 12:59 |
| mgz | with seperate branches, you can just revert a messy merge conflict without worrying, because the other branch still has all your work right there | 12:59 |
| spiv | ("that sort of mess" == having uncommitted changes mixed in with changes merged from another branch in a way that's hard to undo) | 13:00 |
| crisb | hmm that's true. ok so i do my bind, then update and I get loads of conflicts. yikes! so no way I can get out of it without resolving all conflicts? | 13:01 |
| crisb | (without a breakdown) | 13:02 |
| crisb | :) | 13:02 |
| mgz | not easily, nope. | 13:03 |
| crisb | hmm i wonder how that's never happened before then | 13:03 |
| mgz | whereas with a feature branch you can declare conflict bankruptcy at any point | 13:04 |
| crisb | the 'binders' team = largish and mainly inexperienced | 13:04 |
| crisb | my team = small and very experienced | 13:04 |
| spiv | crisb: if you've always committed the changes before updating (even just local commits) you don't get the problem | 13:05 |
| crisb | spiv: why not? | 13:05 |
| spiv | crisb: but really, it sounds like you're trying to have a feature-branch workflow, so just use branches :) | 13:05 |
| spiv | crisb: because you can recover a committed state (that's large part of the point of committing it!) | 13:06 |
| mgz | my impression is documenting a sensible way of working for the binders bunch based on what your guys do is a better use of your time than writing a plugin to make their way less error-prone | 13:06 |
| spiv | crisb: but if you haven't committed, and then do a conflicting update then you don't have a way to 'bzr revert' (or any other simple command) back to the the state you had just before the update | 13:08 |
| mgz | as for why they've not had issues... you can get out of a lot of trouble by blowing away history | 13:08 |
| mgz | but it's generally best not to. | 13:08 |
| crisb | mgz: agreed, i'm more of a fan of educating people than walled gardens, but i'm just the plugin guy :) | 13:08 |
| crisb | i think they basically want to avoid the whole gatekeeper issue | 13:10 |
| crisb | automated or not | 13:10 |
| crisb | but i dont really think that goes hand in hand with a plugin that treats everyone like a moron.. | 13:11 |
| crisb | because if they cant even work out when they've not updated to the master copy, why would you trust them to fix any conflicts they come across? there's no oversight then, their way of fixing the conflicts is on the trunk. | 13:13 |
| crisb | or am i missing something? | 13:13 |
| mgz | with better errors (which merging into a bound pristine trunk should give over the current way) and a few cheat sheet things like how to use --take-this and --take-other in bzr resolve, it should be harder to get wrong | 13:17 |
| crisb | hmm it's harder to sell though, because they then need to do a separate merge on another tree which could lead to more mistakes | 13:18 |
| mgz | well, it's the same underlying steps, seperating out the update from the merge means forgetting the update is safe | 13:24 |
| mgz | you get prompted if you try to commit to the bound branch if it's not up to date, then if you blow things up doing update, you can just revert and merge the feature branch again | 13:25 |
| === deryck is now known as deryck[lunch] | ||
| === vednis is now known as mars | ||
| === deryck[lunch] is now known as deryck | ||
| === zyga_ is now known as zyga | ||
| === zyga_ is now known as zyga | ||
| bobweaver | Hello there is there a mailing list for the development of bzr and or bzr explorer as I am using them 20 + times a day. so if there is mailing list of up and coming things that are happening I would love to know thanks for your time | 22:12 |
| sagaci | http://wiki.bazaar.canonical.com/BzrSupport | 22:16 |
| bobweaver | Thanks | 22:17 |
| Noldorin_ | ho hum | 22:36 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!