>>
>> My concern with such a scheme is how (*) to transplant changes from cedet
>> into
>> an emacs subdirectory, such that all cedet commit logs and dates are
>> maintained.
>>
> An easier setup:
> The CEDET branch (where CEDET programmers make most changes) is a branch of
> Emacs' trunk (done by: bzr branch http://bzr.savannah.gnu.org/r/emacs/trunk/
> cedet).
[...]
> This setup has the disadvantage of taking a little more space in disk for
> the CEDET branch (because you handle much more than CEDET), but other than
> that, it's very easy.
This takes a whole lot more space to have local copies, and in the case of bzr
this translates into much slower operations.
Besides, there's people using other emacs' flavours.
What we ought to know is how to easily transplant changes and commit
information.
In order to make such merges look good in the log history (e.g., "merge from
cedet trunk"; such that not all cedet individual commit messages are visible in
the "top-level" commit messages), the cedet -> emacs merge should be something
like:
* create new branch in emacs for the sole purpose of the merge
* transplant changes maintaining author, log and date information
* record in a file which revisions have been merged and/or discarded for
merge (those not recorded will be candidate for merge in posterior runs
of the script)
* merge this branch wherever it fits
* delete branch
I'm sure a simple script could be written to perform points 2 and 3 for each
revision, and another to show a log only with the revisions not listed in the
aforementioned file.
apa!
--
"And it's much the same thing with knowledge, for whenever you learn
something new, the whole world becomes that much richer."
-- The Princess of Pure Reason, as told by Norton Juster in The Phantom
Tollbooth