Hugo Cornelis writes:
> On Tue, Feb 23, 2010 at 2:58 AM, Stephen Leake
> wrote:
> > hend...@topoi.pooq.comhendrik writes:
> >
> >> [ Code that is used with multiple projects/ split/merge; hard to handle ]
> >
> > I don't understand the issue. What, exactly, do you mean by "include
> > both
On Tue, Feb 23, 2010 at 2:58 AM, Stephen Leake
wrote:
> hend...@topoi.pooq.comhendrik writes:
>
>> Let's say I have some code checked in along some branch. Over the year
>> it has evolved so that it has become two separate programs, that don't
>> share any code any more, and make sense to develop
hend...@topoi.pooq.comhendrik writes:
> Let's say I have some code checked in along some branch. Over the year
> it has evolved so that it has become two separate programs, that don't
> share any code any more, and make sense to develop independently.
>
> Evidently, it makes sense to make two b
The other method is to make a quick commit with --branch=program1
branch pivot_root < program1's new root directory> old_root - will
put all files in the root into old_root and make the program
directories current. You can then use mtn drop to drop old_root.
this is bad, in that you cannot propa
There's the more immediate case, even, of discovering that part of one
project is really a module that should be shareable - you'd like to pull it
out into its own branch, delete files on both sides, and then merge_into_dir
the module's branch. Alas, since they share a common parent, this is
forbi
Let's say I have some code checked in along some branch. Over the year
it has evolved so that it has become two separate programs, that don't
share any code any more, and make sense to develop independently.
Evidently, it makes sense to make two branches, one for each program.
The obvious way i
