at the moment, i'm working my way thru the subversion book, but i
thought i'd ask for some general advice on how best to structure a
repository (or collection of repositories) for a current project.
imagine a project to build a downloadable, bootable image for an
embedded linux system. currently, all of the source is in a single CVS
repository, and consists of subdirectories containing all of the stuff
you expect you'd need to build that kind of image:
- kernel source tree
- busybox source
- shared libs directory
- additional utility source directories, like PPP
and on, and on. sitting on top of all of this is the ubiquitous makefile,
which does a recursive make to build all of the source, then crunch it all
together into a single binary, downloadable image which is the combination
of the kernel and root filesystem. so far, so good. i'd like to move all
of this over to subversion, but i'd like to make some major changes to the
structure.
in the first place, while there's only one project at the moment (call
it project A), who's to say that we won't decide to start a second project
B, which could use a lot of the content from A? perhaps project B might
be based on the exact same kernel source tree. perhaps it might also
incorporate busybox, or PPP. in short, i want to treat the collection of
source as more like a set of separate repositories from which i can pick
and choose the parts to start a new project. no sense duplicating the
same source time after time, *especially* if new projects will use the
same changes we made to the original source.
on the other hand, while a new project might want to use the same
*original* kernel source tree, perhaps it's going to be run on a slightly
different board. so while multiple projects might *start* with the same
pristine kernel source version, they all might need different branches if
they need to be tweaked differently.
and how about making things just a little trickier? say we need to
modify the actual kernel source to get, for example, USB host support on
our little processor. perhaps not all projects need USB support, so we
might want to keep the USB changes as a separate branch, and merge that
branch only for those projects that need it. but wait. say we want to
start some new projects with, not the current 2.4 kernel, but the 2.6
kernel. we'd still like the ability to (if possible, of course) start
with the pristine 2.6 kernel source tree and merge things like USB changes
from existing branches that came off the 2.4 kernel source tree.
(naturally, depending on how drastically the kernel source tree has been
modified between 2.4 and 2.6, old branches might not be mergeable at all.
not much we can do about that.)
get the idea? sorry for being so vague, but in a nutshell, what i'm
trying to build is a repository of parts (and branches), from which i can
checkout just those parts (and branches) i need to start a new project.
as an example, i can imagine thinking:
"i want to start a new project based on the 2.6 kernel, with the USB
host support stuff merged, and the flash filesystem merged as well. with
that, i'd like the busybox component, plus PPP." etc, etc. so i'll
check out the components, and just design the make structure around those
parts.
am i asking a bit much here? comments, anyone?
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Mar 21 14:34:16 2004