[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggestions for using CVS with a system/software project
From: |
Mark D. Baushke |
Subject: |
Re: Suggestions for using CVS with a system/software project |
Date: |
Mon, 01 Dec 2003 23:41:13 -0800 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dustin Puryear <address@hidden> writes:
> I have a project that combines custom software, FreeBSD, and some software
> initially grabbed from FreeBSD ports. (We use the FreeBSD ports version
> because any FreeBSD-patches to the software have been done for us.) We do
> not use new versions of any software from ports unless we do thorough
> testing--we would rather keep to a single version of each software so that
> we know about the bugs, specific implementation, etc. In addition, we
> customize some ports packages, so grabbing the latest and greatest isn't
> beneficial.
>
> The proposed CVS layout that I have so far is as follows:
>
> projectname/kernel
> projectname/tools/X
> projectname/tools/Y
> projectname/tools/Z
> projectname/userinterface
> projectname/component/softwareX
> projectname/component/softwareY
> projectname/component/softwareZ
> ...
>
> Anything under projectname/tools/ is custom. In addition, various software
> under projectname/component/ may be custom developed, customized from ports,
> or customized from downloaded source. By 'component' I mean to imply that
> this software works together in some fashion to deliver a service, or is in
> some way a core component of the software. projectname/kernel/ is a
> customized FreeBSD kernel.
>
> In my mind, we have three types of software to worry about:
>
> 1. custom developed - goes into CVS just like any custom software package
> being developed.
Sure.
> 2. customized, existing software - if we are grabbing the software from
> ports should we just check that into CVS like we would with any other
> customized source?
You will probably find it easier to import the baseline version and then
commit your code on top of it.
> I would say that we are relying on 20-30 ports packages
> (we only need a few services, but the dependencies grab a lot of other
> software). So in this case we need to check in 20-30 source packages?
Sure.
> If we decide to grab a new release from ports we would just check that
> in on top of the existing source?
Or, import it and then do a merge of your changes forward.
> Should we consider a special directory for this?
Possibly. FreeBSD uses a contrib hierarchy in their src tree to allow
themselves to have the Makefile glue kept separately.
> projectname/kernel
> projectname/tools/X
> projectname/tools/Y
> projectname/tools/Z
> projectname/component/softwareX
> projectname/component/softwareY
> projectname/component/softwareZ
> projectname/freebsd-ports/softwareX
> projectname/freebsd-ports/softwareY
> projectname/freebsd-ports/softwareZ
> ...
>
> 3. non-customized, existing software
>
> We have some software that we use from ports, and we depend on
> specific versions. Should we just keep a copy of tgz in an archive
> outside of CVS, or should we insert this into CVS too?
That is up to you, you might find it useful to keep it in cvs as a
source reference, but keeping 'golden' release tarballs has its place as
well.
> Often, we just install the software and then one of our tools creates
> a customized configuration for it. Should we be checking in the
> configuration files then? Our tools overwrite them anyway, and we
> aren't really customized the configuration files by hand.
That is hard to say... there are arguments for both positions. If the
'seed' configuration might be used in a vanilla way and might change
later, you might want to understand why and when those changes to the
initial configuration were introduced and/or have a process to audit
what changes have been made to your product over time.
-- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/zEIZ3x41pRYZE/gRAmPEAKDd5YyENEGTVgrBxHLea4Mj//KZYgCeJxCB
X42H8SsRd6noB2Gn0WvRWoA=
=cLHo
-----END PGP SIGNATURE-----