=== wgrant_ is now known as wgrant
mgrandii'm still confused on how to do conflict resolution. every 'tool' ive tried sucks or does it wrong00:07
mgrandimight as well just edit them by hand00:07
Noldorinmgrandi, OS?00:13
mgrandiany of them, mac windows or linux00:13
Noldorinat the worst, use bzr resolve from the command line00:13
Noldorinon windows i use winmerge00:13
Noldorinkdiff3 is also fine on windows and linux00:13
mgrandiwell what file should it be 'merging into'00:13
mgrandiis really my question00:14
mgrandithe one i was using was merging everything into base, and bzr doesn't like that00:14
Noldorinyeah, merge into the normal file00:15
Noldorinno extra extension that is...00:15
mgrandicause the one i was using on mac, DiffMerge asked me for the left right and 'ancestor file'00:16
mgrandiand that was this other and base, and had me merge into base..00:16
Noldorinmgrandi, read that00:18
Noldorindownload WinMerge and/or KDiff300:18
Noldorinthey are the best tools, at least on Windows00:18
Noldorinand then you're sorted00:18
Noldorinuse bzr qresolve for a GUI resolve00:18
Noldorinor specify via the command line00:18
Noldorinso yeah, actually you can merge "into" any of those 3 files00:19
Noldorinbut bzr looks ofr an extensionless one at the end00:19
Noldorinso you either have to create a new file that is the result of the merge...or rename an old one00:19
=== spiv_ is now known as spiv
vivekimsitI 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
spivvivekimsit: depends on what you want to do :)06:34
spivvivekimsit: you might want to use 'bzr update', and integrate both sets of changes06:34
spivvivekimsit: 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
mgzwonder if isp has reason for net having been down all night...08:25
fullermdThe electrons were spun down for refueling.08:35
=== fredp` is now known as fredp
crisbis there a hook I can use that only gets run when doing a bzr update?12:28
jelmercrisb: you can use the post_branch_tip_change hook, but that gets called for pull and push too12:29
jelmercrisb: another option is to register a command hook and in that hook check if the command being run is update12:29
mgzright, command hooks were added in 2.6, but you probably want one of the branch changed ones really12:30
crisbcan 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 at12:33
crisbsure, 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 unbind12:35
mgzwhat prompted this? people pulling from the wrong branch?12:38
crisbmore like people doing update when unbound, finding no changes and then assuming they have the latest.12:38
mgzI 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 parent12:39
mgzI'd suggest instead of a hook touching update,12:39
mgzthat 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 instead12:40
mgzupdate does useful things not related to getting the newest code in a bound branch, changing that behaviour in a plugin is likely to break things12:41
crisbwhat makes it a funny workflow? (it's not my workflow so i'm not necessarily saying I dont think it's funny :)12:42
mgzif I understand correctly, people have a bound, but non-pristine, copy of a remote trunk, which is just asking for accidents12:43
mgzeither 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 date12:44
crisbsort 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 unbind12:45
mgzor just a copy of trunk that `bzr pull` will update12:45
mgz^right, that seems to be asking for problems to me12:46
mgzis this a huge project that people don't want more than one working tree of around at a time?12:46
crisbnot massive no12:47
crisbthey're heavyweight checkouts anyway12:47
mgzjust seperating out the branch for hacking on from the copy of trunk would simplify things no end12:47
crisbyou're talking about having feature branches which someone merges onto the trunk?12:48
mgzright, which is basically what they're doing currently, but by unbinding trunk to diverge rather than branching12:48
crisbok thats how my team operates12:49
crisbthey branch, hack, push to a dev location, i merge them in.12:49
mgzthey can still merge onto a local bound trunk themselves when they're done12:49
mgzbut with a merge between the two local branches operation, rather than bind/update12:50
crisbthis would avoid losing the history of their local commits too wouldnt it12:50
mgzthe history is always there, log just shows the mainline only by default12:51
crisbsorry i mean if you bind to a trunk all your local updates become uncommitted and the history lost right?12:51
mgzhm, I'm not totally sure what happens in that case as I've never tried binding a diverged branch, but it's something like that12:52
crisbok so you're saying have two copies of the branch, one bound, one unbound.  hack on the unbound one then merge using the bound one12:53
mgzokay, so the effect is the same as the merging would be, your local commits get moved to a pending merge on the right hand side12:55
mgzcrisb: right, that's simpler to get right I think12:56
mgzand when something goes wrong, it's easier to fix it too12:56
crisbhow so?12:57
mgzthe bind/update thing makes it hard to recover your local state if you can't commit12:57
crisbhmm why wouldnt you be able to commit?12:59
spivEspecially 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
mgzwith seperate branches, you can just revert a messy merge conflict without worrying, because the other branch still has all your work right there12: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
crisbhmm 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
mgznot easily, nope.13:03
crisbhmm i wonder how that's never happened before then13:03
mgzwhereas with a feature branch you can declare conflict bankruptcy at any point13:04
crisbthe 'binders' team = largish and mainly inexperienced13:04
crisbmy team = small and very experienced13:04
spivcrisb: if you've always committed the changes before updating (even just local commits) you don't get the problem13:05
crisbspiv: why not?13:05
spivcrisb: but really, it sounds like you're trying to have a feature-branch workflow, so just use branches :)13:05
spivcrisb: because you can recover a committed state (that's large part of the point of committing it!)13:06
mgzmy 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-prone13:06
spivcrisb: 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 update13:08
mgzas for why they've not had issues... you can get out of a lot of trouble by blowing away history13:08
mgzbut it's generally best not to.13:08
crisbmgz: agreed, i'm more of a fan of educating people than walled gardens, but i'm just the plugin guy :)13:08
crisbi think they basically want to avoid the whole gatekeeper issue13:10
crisbautomated or not13:10
crisbbut i dont really think that goes hand in hand with a plugin that treats everyone like a moron..13:11
crisbbecause 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
crisbor am i missing something?13:13
mgzwith 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 wrong13:17
crisbhmm it's harder to sell though, because they then need to do a separate merge on another tree which could lead to more mistakes13:18
mgzwell, it's the same underlying steps, seperating out the update from the merge means forgetting the update is safe13:24
mgzyou 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 again13: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
bobweaverHello 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 time22:12
Noldorin_ho hum22:36

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!