[Monotone-devel] [best practices] How to merge a large code dump with no history?
I just received a pretty large code dump for Botan that adds a number interesting things. However all the changes are mixed together (about 10 distinct changes). And one change, that converts all bare pointers to either shared_ptr or auto_ptr, changes nearly every file. I have currently just moved a version into mtn based against the same version of Botan they used and reverted changes that definitely wouldn't go into mainline (deleting algorithms, mostly). This seems like it would be the easiest way to handle further code dumps in the future as well (I can just unzip into a workspace). But if I check this in as a new branch, how do I get singular changes out again? What is the best way to deal with a situation like this with mtn? `pluck`? A merge tool trick? 'Don't do that then'? -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
Jack Lloyd writes: I just received a pretty large code dump for Botan [...] I thought Botan used monotone upstream? Am I mistaken? -- Ludovic Brenta. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
On Sat, 2008-05-24 at 09:33 -0400, Jack Lloyd wrote: I just received a pretty large code dump for Botan that adds a number interesting things. However all the changes are mixed together (about 10 distinct changes). And one change, that converts all bare pointers to either shared_ptr or auto_ptr, changes nearly every file. I have currently just moved a version into mtn based against the same version of Botan they used and reverted changes that definitely wouldn't go into mainline (deleting algorithms, mostly). This seems like it would be the easiest way to handle further code dumps in the future as well (I can just unzip into a workspace). But if I check this in as a new branch, how do I get singular changes out again? What is the best way to deal with a situation like this with mtn? `pluck`? A merge tool trick? 'Don't do that then'? I'd go with don't do that then (to the big dump, not the wanting to split it). But since someone *did* do that, maybe commit in a branch (which nobody should ever merge back), undo the different changes individually (lots of annoying work, but at least you have the help keeping track of where you are), and pluck each undo backwards (mtn pluck -r child -r parent). Or ask them to split it for you and re-send. :) ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
On Sat, May 24, 2008 at 05:57:49PM +0200, Ludovic Brenta wrote: Jack Lloyd writes: I just received a pretty large code dump for Botan [...] I thought Botan used monotone upstream? Am I mistaken? Yes. I use Montone for my VCS working on Botan and other things. But the people who sent me patches do not. I just got a .zip file of sources. [To clarify: this is a Montone usage question, not a development-of-Montone-related question] -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] [best practices] How to merge a large code dump with no history?
On Sat, 2008-05-24 at 17:57 +0200, Ludovic Brenta wrote: Jack Lloyd writes: I just received a pretty large code dump for Botan [...] I thought Botan used monotone upstream? Am I mistaken? Yes, Jack Lloyd is Botan upstream. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
