| mgrandi | anyone here? :> | 04:58 |
|---|---|---|
| mgrandi | need help with merging =( | 05:03 |
| fullermd | Vaseline and a crowbar? | 05:06 |
| mgrandi | haha | 05:07 |
| mgrandi | so say we have a branch | 05:08 |
| mgrandi | and then we have newer version of code that we want to merge into this branch | 05:08 |
| mgrandi | but how can we make bzr merge this newer version into the branch? apparently bzr can't do it because the file ids are different in the 'new' code | 05:09 |
| mgrandi | so it just moves the old code to .moved and puts the new stuff in place | 05:09 |
| bob2 | why did you do that | 05:09 |
| mgrandi | its 'generated' code | 05:10 |
| mgrandi | well thats why im asking on how to do it since that isn't working =P | 05:10 |
| bob2 | fix your system | 05:10 |
| bob2 | so the ids match | 05:10 |
| fullermd | If the file-id's are different, you're out of luck. Your choices turn into "remake things so they're the same", "pick one over the other", or "take up cobbling" | 05:11 |
| mgrandi | so there is no way to do it if the ids don't match at the moment? | 05:11 |
| mgrandi | hmm. | 05:11 |
| fullermd | If both branches have nontrivial history, remaking becomes a lot harder. If they're out in the wild, that verges well into impractical. | 05:11 |
| bob2 | fix your things | 05:11 |
| mgrandi | well its crappy cause its not our code, we are decompiling it | 05:12 |
| bob2 | you should have used bzr-load-dirs or similar to get the vendor code in | 05:12 |
| fullermd | In the wild, one-over-another becomes pretty impractical too, unless you can coordinate the universe. | 05:12 |
| mgrandi | and we are trying to fix it | 05:12 |
| bob2 | how did you even make this happen | 05:12 |
| mgrandi | what is bzr load dirs? | 05:12 |
| bob2 | the thing that you google | 05:12 |
| bob2 | did you "bzr rm -r * ; SPLOOSH RANDOM FILES EVERYWHERE ; bzr add . ; bzr commit -m 'teh import'"? | 05:13 |
| mgrandi | we decompiled the code, and started versioning / editing that | 05:13 |
| mgrandi | only reference i to see about bzr-load-dirs is from you in 2009 o.o | 05:14 |
| bob2 | no idea how you got the code into bzr | 05:15 |
| bob2 | but even "bzr branch whocares ; SPLOOSH FILES ; bzr add ; bzr commit -m'update import'" mostly works | 05:15 |
| mgrandi | but git-load-dirs looks like what we want, but i dunno where the bzr version is | 05:15 |
| fullermd | You could transistion stuff into git, do merges, then pull it back into bzr. But that's a long way around to the "pick one over the other" case too; one of the branches would have to be dead afterward. | 05:16 |
| bob2 | what commands did you run | 05:16 |
| fullermd | (or perhaps it's more of a "pick a third over each", and both branches dead afterward) | 05:16 |
| bob2 | I can only see you being in this situation if you did a "bzr rm theworld" | 05:16 |
| bob2 | is that what happened? | 05:17 |
| mgrandi | i mean we haven't commited anything yet, we just got to the 'pending merge' etc | 05:17 |
| bob2 | yes you have | 05:18 |
| bob2 | you did something to your vendor branch | 05:18 |
| bob2 | what did you do? | 05:18 |
| mgrandi | just tried putting the newly decompiled code into a new branch and tried to merge that into the stuff we were walking on | 05:18 |
| bob2 | yes a new branch obviously won't work | 05:18 |
| bob2 | clone the previous dump | 05:18 |
| mgrandi | there wasn'ta vendor branch yet, thats what we are going to add soon, which is probably the problem | 05:18 |
| bob2 | sploosh your new source tree all over it | 05:18 |
| bob2 | bzr add . | 05:18 |
| fullermd | It's not hard in concept to remake a history with arbitrary id's. I don't know if anybody's written an automated process for it, and the hard part is it means you have to throw away and forget completely the "old" version, which is hard in an open-source world (easier, though not necessarily easy, in a closed env) | 05:19 |
| bob2 | bah | 05:20 |
| bob2 | that's insane | 05:20 |
| bob2 | full solution: | 05:20 |
| bob2 | clone previous dump of crap | 05:20 |
| bob2 | mkdir ../keep | 05:21 |
| bob2 | mv .bzr* ../keep | 05:21 |
| bob2 | rm -r * | 05:21 |
| bob2 | mv ../keep/.b* . | 05:21 |
| bob2 | sploosh new pile of code into current dir | 05:21 |
| bob2 | bzr add . | 05:21 |
| bob2 | bzr commit -m "update to SOME VERSION IDENTIFIER OF THIS THING" | 05:21 |
| bob2 | then you're done | 05:21 |
| fullermd | What previous dump? The world is full of real cases of parallel imports. You're kinda flirting with the line between "amusing" and "insulting"... | 05:22 |
| fullermd | If there's no history on one side or the other, it's easy. If there is, life gets a lot harder. | 05:22 |
| bob2 | ? | 05:22 |
| bob2 | I'm 99% sure mgrandi is saying "we get dumps of some binary crap from some people on a regular basis, then decompile it, and we'd like each version to be in bzr" | 05:23 |
| mgrandi | yeah | 05:23 |
| bob2 | which the above works for | 05:23 |
| fullermd | I read it more as "we've got two different sets of working on the same dumps that started independently, and now we're trying to combine them" | 05:24 |
| fullermd | (FSVO "same") | 05:24 |
| mgrandi | its the "vendor branches" concept pretty much, looking into whatever_load_dirs scripts that bob2 referenced | 05:25 |
| bob2 | all bzr-load-dirs does is the above | 05:26 |
| bob2 | the above is the complete set of steps required | 05:26 |
| mgrandi | do you have a link to that? i cannot find that on google | 05:26 |
| mgrandi | only svn/git/tla load-dirs | 05:26 |
| bob2 | nope | 05:27 |
| bob2 | but seriously, it's 10 commands to run | 05:27 |
| mgrandi | ok | 05:31 |
| jelmer | hi | 08:14 |
| mgrandi | hi | 08:18 |
| mgz | morning | 08:29 |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === yofel_ is now known as yofel | ||
| === deryck is now known as deryck[lunch] | ||
| === deryck[lunch] is now known as deryck | ||
| foobaz | What's the best way to include external dependencies in a bzr project? (e.g. like svn:externals) | 19:23 |
| foobaz | I'm presently scripting bzr checkout... | 19:24 |
| foobaz | maybe there's a better way. Thanks. | 19:25 |
| jelmer | foobaz: there's bzr-externals, or bzr-scmproj I guess | 19:27 |
| foobaz | jelmer: thanks! I'm evaluating those two | 20:29 |
| tbf | am i just biased, or does "bzr merge" sometimes just overwrite local changes instead of creating conflicts? | 20:30 |
| tbf | no. i just caught that guy | 20:33 |
| tbf | have a merge commit where bzr cleary overwrote a local change | 20:33 |
| tbf | junk scm | 20:33 |
| lifeless | tbf: by local change, do you mean uncommitted change, or change only on your branch ? | 20:36 |
| tbf | lifeless, a change commited to a local branch | 20:37 |
| lifeless | tbf: the former should conflict unless identical to incoming changes; the latter likewise, but if someone has merged you, then reverted that change, and then you merge them, the change will go away. | 20:37 |
| tbf | lifeless, ok. checking commit history | 20:37 |
| tbf | (and i please want git style rebasing) | 20:38 |
| tbf | lifeless, no. there is only once commit where a team mate change the line above the lost line | 20:41 |
| tbf | branching the current state for backup, uncommiting, redoing the merge | 20:42 |
| tbf | double checking i didn't do a mistake | 20:42 |
| tbf | ok. it's late and i am overworked. | 20:46 |
| tbf | ...and biased. | 20:46 |
| fullermd | ENOTENOUGHCOFFEE 8-} | 20:46 |
| tbf | lifeless, sorry for confusion. | 20:46 |
| tbf | fullermd :-) | 20:46 |
| lifeless | tbf: np | 20:46 |
| === lifeless_ is now known as lifeless | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!