based on a question i asked once upon a time, i just want to know if i
can do the following.
my original post asked about how to define a software project by picking
and choosing from a collection of software components, and someone
suggested the obvious solution of using "svn:externals", which looks like
it will do the job nicely.
given the svn:externals property, my plan is to create a separate
repository of software components that new projects can pick from --
components that would include a 2.4 kernel source tree, a 2.6 tree
(perhaps more than once version of each), perhaps a couple different
versions of busybox, and so on. this repository would include pure
source, and nothing else -- no build scripts or makefiles, at least i
don't think so yet. the repository's job is to handle strictly source.
anyone defining a new project would simply have to define how they
want their working copy structured, define the svn:externals they need,
and create the entire build/compile structure around those parts. and
here comes the question.
if we consider two projects -- A and B -- that both pull in the 2.4
kernel source tree, it's possible that either of those projects might need
to hack the actual kernel source, and create a new branch that's
developing a new feature; say, fancier USB support.
in some cases, this additional feature might be restricted to project A;
in other cases, this feature might need to be incorporated back into the
repository. although i haven't nailed down how to do this yet, i'm
assuming it's not going to be hard for a project to define new branches in
either of two places -- strictly within the current project, or back in
the main software repository. is that doable?
(it also might get messier -- i might have a project working with a 2.4
kernel, having created a branch for a special feature, then later i'll
want to try to merge that branch into the 2.6 kernel to try to add that
fancy new feature to the 2.6 kernel.)
thoughts?
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Apr 3 21:00:05 2004