i'm working my way thru the SVN book, and i have a question on
something i'd like to do and whether it's
1) doable and straightforward, and/or
2) whether it's not really the way one should do SCM
i'm working on an embedded linux project that i'd like to move from
CVS to SVN, and it incorporates a number of third-party components:
- linux kernel
- PPP
- minit
- busybox, etc, etc.
as the project progresses, there are two ways that some of these
3rd-party sources might be updated.
first, new versions will inevitably come out, and we'll want to
upgrade from, say, linux 2.6.8 to 2.6.9. or PPP 2.4.2 to 2.4.3. and
so on. that part's easy.
the other way to upgrade any of these sources will be with, not
surprisingly, local hacks. i say "hacks" since, as much as possible,
i *don't* want to make local mods to 3rd party sources -- i want to
keep the 3rd party stuff pristine, and only make changes that
represent a temporary fix to something we can hope will be fixed in
the next version. (as an example, if we *need* to hack PPP so that it
works for us, i'm going to convince myself that it's something that
should be fixed in PPP anyway, and i'll submit that fix upstream. in
short, local mods to 3rd-party sources should be viewed as strictly
temporary and things to be abandoned as soon as they're not needed
anymore.)
so, the normal progression for a single piece of 3rd party software
might be, for example:
3.0 (original pristine version that we started with)
3.0 + a local patch
3.0 + another local patch
3.0 + a third local patch
3.1 (start from scratch again, might not need any local patches)
3.1 + the previous second local patch (if it turns out we still
need it even for 3.1)
as you can see, the idea is, when we get a new version, we *really*
try to not bring any local patches forward unless we absolutely have
to and, even then, we do it selectively. (in a perfect world, we have
*no* local patches being applied to 3rd party source. ok, i've
flogged that idea pretty thoroughly.)
(if that's too easy, let's throw in another challenge. obviously,
we might want to revert to an earlier revision of some piece of
software, but not just any of the above. it might be that i'd like to
go back and use version 3.0, with the first and third patch applied to
it, but not the second. so each local patch has to be tracked
separately and applied as needed.)
what's the normal recipe for doing something like this? if it's
somewhere in the book, a pointer will do fine. or am i making life
difficult for myself, and i should be looking at this in another way?
thanks for any tips.
rday
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Dec 18 18:04:03 2004