as a subversion newbie, i'm looking for some advice on how to track
changes to a kernel source tree. here's the story.
a current software project has, as one of its components, a linux kernel
source tree. from the original tree, we've added extra functionality (USB
support, flash support, etc.) by actually modifying some of the source
files themselves. each addition in functionality (say, flash support)
might represent, not surprisingly, changes to several different files over
several different directories.
currently, we're using CVS and just checking in the changes, without any
regard to tracking which changes are really related to the same
functionality, or tracking diffs between the new files and the original
source tree. here's what i'd really like.
starting from a fresh kernel source tree, i'd like to track everything
related to a single feature (again, say flash support) and, in a sense,
keep all those related changes independent from the source tree, and be
able to apply them whenever we build a new kernel.
the reason i'd like to somehow keep them independent is that i want the
ability to swap out the current 2.4.x kernel with a 2.6.x kernel and, if
it's even possible, apply those changes to the new 2.6 source tree. at
the moment, this isn't even remotely possible -- we've just been blindly
adding CVS changes, so there's not much change of going back and saying,
"gee, i'd really like to collect all checkins related to USB support."
i mean, the checkin comments might refer to USB support, but we've made no
attempt to support branches or anything like that, so trying to take all
those changes and apply them to a brand new source tree is pretty much
i'm still reading the subversion docs, but is there a clean way to do
this? in effect, i want to start my repository with pristine kernel
source and keep track of all additions/changes/deletions grouped by
functionality, so i can replace the source tree with a newer version at
some point, and at least have a hope of applying all those changes to the
new source tree.
i realize there's no guarantee of success here. there were pretty
massive changes between 2.4 and 2.6, so i'd expect that some of the
changes might still apply, while we might need manual intervention for
others. but at least it would be a start.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Mar 15 17:09:21 2004