From 95b3720cef917ac584fb534827ac7e1cf613b5fe Mon Sep 17 00:00:00 2001 From: Hiten Pandya Date: Sun, 25 Jul 2004 16:17:31 +0000 Subject: [PATCH] Merge revision 1.8 and 1.9 from FreeBSD -CURRENT, i.e., add a section on maintaining a local branch. Noticed-by: Maxim Konovalov --- share/man/man7/development.7 | 59 ++++++++++++++++++++++++++++++++++-- 1 file changed, 57 insertions(+), 2 deletions(-) diff --git a/share/man/man7/development.7 b/share/man/man7/development.7 index 140c225536..f2e0944f6e 100644 --- a/share/man/man7/development.7 +++ b/share/man/man7/development.7 @@ -3,7 +3,7 @@ .\" the FreeBSD source tree. .\" .\" $FreeBSD: src/share/man/man7/development.7,v 1.4.2.2 2003/05/23 07:48:35 brueffer Exp $ -.\" $DragonFly: src/share/man/man7/development.7,v 1.4 2004/07/25 16:14:37 hmp Exp $ +.\" $DragonFly: src/share/man/man7/development.7,v 1.5 2004/07/25 16:17:31 hmp Exp $ .\" .Dd December 21, 2002 .Dt DEVELOPMENT 7 @@ -366,7 +366,7 @@ then it is typically going to be an NFS mount on the client. Simply unmounting /usr/obj will leave you with a /usr/obj that is a subdirectory in /usr which is typically local to the client. You can then do builds to your heart's content! -.Sh MULTIPLE VERSIONS OF THE SOURCE TREE +.Sh MAINTAINING A LOCAL BRANCH I have described how to maintain two versions of the source tree, a stable version in /FreeBSD/FreeBSD-4.x and a current version in /FreeBSD/FreeBSD-current. @@ -382,6 +382,61 @@ your master server, but being able to collect and manage source distributions from a central server is a very useful thing to be able to do and you can certainly export to machines which can build those other operating systems. +.Pp +Many developers choose to maintain a local branch of +.Fx +to test patches or build a custom distribution. +This can be done with CVS or another source code management system +(SubVersion, Perforce, BitKeeper) with its own repository. +Since the main +.Fx +tree is based on CVS, the former is convenient. +.Pp +First, you need to modify your cvsup environment to avoid it modifying +the local changes you have committed to the repository. +It is important to remove the "delete" keyword from your supfile and to +add the CVSROOT subdirectory to your refuse file. +For more information, see +.Xr cvsup 1 . +.Pp +The +.Fx +version of CVS examines a custom environmental variable, +CVS_LOCAL_BRANCH_NUM, which specifies an integer to use when doing a cvs +tag/rtag. +Set this number to something high (say 1000) to avoid colliding +with potential future branches of the main repository. +For example, +branching a file with version 1.4 produces 1.4.1000. +Future commits to this branch will produce revisions 1.4.1000.1, +1.4.1000.2, etc. +.Pp +To fork your local branch, do: +.Bd -literal -offset 4n +cvs rtag -r RELENG_4 -b LOCAL_RELENG_4 src +.Ed +.Pp +After this, you can check out a copy from your local repository using the +new tag and begin making changes and committing them. +For more information on using cvs, see +.Xr cvs 1 . +.Pp +.Sy WARNING! +The cvsup utility may blow away changes made on a local branch in +some situations. +This has been reported to occur when the master CVS repository is +directly manipulated or an RCS file is changed. +At this point, cvsup notices that the client and server have entirely +different RCS files, so it does a full replace instead of trying to +send just deltas. +Ideally this situation should never arise, but in the real world it +happens all the time. +.Pp +While this is the only scenario where the problem should crop up, +there have been some suspicious-sounding reports of +CVS_LOCAL_BRANCH_NUM lossage that can't be explained by this alone. +Bottom line is, if you value your local branch then you +should back it up before every update. .Sh UPDATING VIA CVS The advantage of using cvsup to maintain an updated copy of the CVS repository instead of using it to maintain source trees directly is that you -- 2.41.0