Last I saw they had a prototype that worked better than they expected.
> In the
>for what it is worth department, we've done this internally and found
>it doesn't work as well as you might hope. Sometimes there are clear
>delinations and you really can move stuff around but most of the time
>there is stuff built on top of the stuff you want to move and there is
>no way for a program to tell the difference between enhancements vs fixes
>to the original change.
I wouldn't expect the system to be able to do that any better than it can
resolve every merge conflict. And at the very least I'd like to be able
link changesets together so that if I pull cset 1 and there is a mandatory
fix applied to it, I at least get a pointer to the changes. Something
like this:
1. Keep the csets separate but link them together. Let the developer
tell the system whether one is an enhancement or a bugfix to the base.
2. Conflicts can be resolved when someone pulls any member of the group.
Stellation is also nice becuase it's built on a SQL database. This gains
you all the features of the DBMS you run it on, like rollback of failed
transactions and point-in-time recovery.
-- Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/