On Fri, Oct 05, 2007 at 03:31:48PM +0100, Stuart Henderson wrote: > On 2007/10/05 16:21, Stefan Sperling wrote: > > On Fri, Oct 05, 2007 at 12:28:09PM +0100, Stuart Henderson wrote: > > > can you send a diff -u with those in please? (I usually 'cvs diff -RuN' > > > against an anoncvs server or local mirrored repository, which includes the > > > version information, is easy to read and apply, and handles added/removed > > > files nicely, but any 'diff -u' would be good) > > > > How do you 'nicely' diff files you've added? > > just "cvs add" them first. ok for files, not for directories.
Right, I never knew 'cvs add' worked for files. I just did a test, and 'cvsdo add' does not seem to work for directories either... :( > (well, it may work against a cvsync'd repo, but I usually ended up > in a mess next time I updated cvsync when I tried that). FreeBSD have a nice hack in CVS to maintain local branches, which sort of works most of the time with repos mirrored with CVSup. Maybe you find this useful. Quoting http://www.freebsd.org/cgi/man.cgi?query=development : First, you need to modify your cvsup(1) 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. The FreeBSD version of cvs(1) examines a custom environmental variable, CVS_LOCAL_BRANCH_NUM, which specifies an integer to use when doing a cvs(1) 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. To fork your local branch, do: cvs rtag -r RELENG_4 -b LOCAL_RELENG_4 src After this, you can check out a copy from your local repository using the new tag and begin making changes and committing them. WARNING! The cvsup(1) utility may blow away changes made on a local branch in some situations. This has been reported to occur when the mas- ter CVS repository is directly manipulated or an RCS file is changed. At this point, cvsup(1) 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. While this is the only scenario where the problem should crop up, there have been some suspicious-sounding reports of CVS_LOCAL_BRANCH_NUM los- sage that cannot be explained by this alone. Bottom line is, if you value your local branch then you should back it up before every update. -- stefan http://stsp.name PGP Key: 0xF59D25F0
signature.asc
Description: Digital signature
