I am working on an embedded project that will be using Linux and we are trying to figure out the best practice method to source control the Linux version. We want to maintain local configure files and various changes but also allow us to update the kernel if we need to.
Does it make sense to make it a "vendor" branch in Subversion? I always thought vendor branches are really not supposed to be modified.
Any thoughts or opinions on what the best way to manage this is?
Use git. Create a branch of your own changes and merge the master from linux-2.6.git from kernel.org. That way you can keep rebasing your modified branch(es) as you go.
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git checkout -b mybranch
... do some changes ...
git add .
git commit -m "commit message"
git pull origin master
git rebase master mybranch
Using a vendor branch is exactly what you want for this purpose. You would maintain a copy of the Linux kernel you're using in a vendor branch, importing new versions of the kernel as necessary. You wouldn't do any of your own work on that branch, but would merge the vendor branch into your own branch which is another copy of the whole Linux kernel. In your own branch, you can make whatever changes you need.
I'm assuming that you are already using Subversion for a different reason. If you have the chance to choose a new system, Git would be a more appropriate choice for a fork of the Linux code base.
You really, really want to keep your kernel in git. If you have to, you could use a vendor branch in SVN to track it from that universe, but work on the kernel itself really has to be done using git.
We've got an embedded linux with the whole OS in git, with a kernel in a submodule. This slightly complicates working in the OS, but the great advantage is that patches from linux git repositories will apply to our kernel, and vice-versa. This is a huge advantage when we have to track development on platform support, wireless, the network stack, and random stuff from mainline, all from different upstream sources.
Essentially, if you don't have your kernel in git, you are in for a world of pain, reimplementing a bazillion patches with no real chance of pushing them back to the community for maintenance... and you will eventually find that you would benefit from that, even if you don't think so now.
I don't know to what extent you want to modify your kernel, but if you only are after small "board file" modification, custom drivers etc..., my advice is not to track the whole kernel, but to use the quilt tool, that allows you to maintain your change as a series of patches, and to put your quilt patches under whatever versionning system you want to use.
I am working on several embedded project, as the single developer, and I have to maintain versioning for the various board we are producing. I tried using git, but then I discovered quilt, which is quite rough, but is very handy when you have to maintain only a small set of patches for a varying number of software projetc, each project moving quite rapidly.
Dont put u-boot, the kernel, busybox, every library you are using under versioning. Instead, use some build tool, like ptxdist, build root, etc..., and only maintain quilt series of patch and configuration files for each package.