=== Guest91097 is now known as fredp
=== fredp is now known as Guest327
[09:36] <quicksilver> how do I pick a version of a file and record that?
[09:36] <quicksilver> if I bzr revert -r123 file.txt
[09:36] <quicksilver> I belive it will rever the text contents of file.txt to the text contents as of revision 123
[09:37] <quicksilver> but it won't reset the rev-id of that file to the revision called 123
[09:37] <quicksilver> does that even make sense
[09:37] <fullermd> What "the rev-id of that file"?  Files don't have revisions, revisions have files.
[09:39] <quicksilver> fullermd: when I do a later merge into another branch
[09:39] <quicksilver> fullermd: I want it to think "this file is current as of rev-id X, so there is nothing to do"
[09:39] <quicksilver> fullermd: and I want it to use X as the basis for the diff it will build when merging
[09:40] <quicksilver> does that make sense?
[09:40] <fullermd> As in forgetting the history and all the changes to it since then?
[09:40] <quicksilver> effectively yes
[09:40] <fullermd> No such thing.
[09:40] <quicksilver> I can make my situation more concrete if you like
[09:40] <fullermd> You'd have to recreate the whole history from that point.
[09:41] <quicksilver> file is in a good state in rev-id A, say
[09:41] <quicksilver> in rev-id B it received massive formatting only changes
[09:41] <quicksilver> in one particular branch, in rev-id C, those formatting changes were accidentally undone
[09:41] <quicksilver> so rev-id C is textually identically to rev-id A
[09:42] <quicksilver> now all the other active branches have the file correctly formatted (B)
[09:42] <quicksilver> if I simply correctly format and commit I believe I will generate a new revision (D)
[09:42] <quicksilver> which might 'look like' B
[09:42] <quicksilver> but because it has more history, it will conflict with branches from branch point B
[09:42] <quicksilver> if they ever make changes to affected lines (which is lots of them)
[09:43] <quicksilver> fullermd: does that sound like it makes sense?
[09:43] <fullermd> Not necessarily; 3 way merge should ignore all the stuff in the middle and just look at the LCA and end products.  Weave merge would probably blow beets on it, to be sure...
[09:44]  * quicksilver googles LCA
[09:44] <quicksilver> common ancestor?
[09:44] <fullermd> But you're essentially talking about changing the contents of a file in a revision [multiple, but same difference].  You can't do that without changing (i.e., replacing) the revision, and you can't do that without replacing all the revisions that follow.
[09:44] <fullermd> So the only feasible way would be recreating some amount of branch history to eradicate the traces of such things.
[09:44] <fullermd> Latest Common Ancestor
[09:44] <quicksilver> nod
[09:45] <quicksilver> I know how to recreate the history, done it before for worse issues than this one
[09:45] <quicksilver> I'll try the text revert and see if I get conflicts!
[09:45] <fullermd> If you're needing to dispose of 2 revs from earlier today that aren't published, that's trivial; if it's 500 revs from the last 6 months that are all over the world...
[09:45] <quicksilver> or even if they're just all over 30 branches in this office it's still a pain :P
[09:46] <fullermd> Quite.  The pain goes all nonlinear as soon as there's more than one copy...
[09:47] <quicksilver> thanks
=== Guest9335 is now known as fredp
=== fredp is now known as Guest59972
=== fredp is now known as Guest23882
[20:34] <fmccann> Hey bzr folks, I’m trying to configure bzr to use vim for resolving conflicts. Is this possible? I’m tring to config either bzr.mergetool or external_merge for the extmerge plugin and I’m not getting anywhere :D