Re: Suggestions for using CVS with a system/software project

[Mark D. Baushke]

-----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-----