Date: Wed, 12 Sep 2007 03:36:38 -0400 From: Tom Huppi <tomh@huppi.com> To: David Christensen <dpchrist@holgerdanske.com> Cc: 'Agus' <agus.262@gmail.com>, 'freebsd-questions' <freebsd-questions@freebsd.org> Subject: Re: Which versioning system is the simplest to use?? Message-ID: <20070912073638.GA51618@huppi.com> In-Reply-To: <00c401c7f4ff$f8959960$0a00a8c0@a64x23800p> References: <fda61bb50709111141h3dc9ae6dxc011c485eea83784@mail.gmail.com> <00c401c7f4ff$f8959960$0a00a8c0@a64x23800p>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22:44 Tue 11 Sep , David Christensen wrote: > Agus wrote: > > I am doing a little bit of security and log watching with sec.pl and > > was trying to mantain de secconf files organized... So whenever one > > is changed it keeps track of the change and can rollback.... > > O that is what i am going to use de versioning sytem for... This is just my experiance on this stuff. There are no right or wrong ways to do it, and happily, all kinds of altrnatives. > If you only have a file or two, I'd suggest RCS. "man rcs" should get you going. > An earlier version of this book helped me understand RCS well enough to write > custom scripts that used RCS on sets of files: > > http://www.oreilly.com/catalog/rcs/index.html I've use RCS pretty religiously for system administration...but in fact rarely do I actually refer back to older revisions in practice. I've always just refered to this document: http://www.samag.com/documents/s=9367/sam9812a/9812a.htm which has been enough to get me by. The biggest hassle is the $LOGNAME deal which can different depending on how one gets a root shell. > Then I heard about CVS, which uses RCS format archive files (so you can use > either tool) and provides the set functionality I needed plus more. "info cvs" > is the online resource, but I did better with an earlier version of the book: > > http://cvsbook.red-bean.com/cvsbook.html > > > I now use CVS to maintain version control of the configuration files on my > various systems. I build a CVS tree which is a sparse mirror of the root file > system. Whenever I want to change a configuration file in the "live" tree, I > copy the intervening directories and/or file into the CVS tree, check everything > in, make my changes, copy the changed filed back to the original location, test, > and repeat the edit/ copy/ test sequence as necessary. When all is well, I check > in the file to CVS. As a variation on a theme, I sometimes move the "live" file > and replace it with a symbolic link into the CVS tree. But this approach can be > messier when you make a mistake and destabilize the system. YMMV. Using CVS in > this way provides for the use cases you've identified, and it also allows me to > check out the trees from other machines to compare/ contrast. Best yet is when I > rebuild a machine -- restoring configuration is a matter of installing CVS, check > out the system configuration file tree, and copying/linking. I tend to use revision control for (software) systems I create or maintain installations of, but find it worthwhile to create a Makefile to actually install the files (and often the system itself.) I find this more flexible in that I can create different targets to do different things, structure my repository differently than the destination, ensure proper ownership and modes of the files, etc. A script would work to, but I happen to know gmake reasonably well. CVS is pretty easy to set up and maintain, and works fine for reasonable source trees in my experiance. CVS is simple enough so that all kinds of games can be played, but often these games (like moving thing in the repository) invalidate revision control at a basic level. My experiance is that people figure out what is possible some time before they figure out what exactly they have done...but also that in practice, it rarely matters. > I suspect that there is are open-source projects that already do much or all of > what I'm doing with CVS. You might want to look or ask around -- try "tripwire". > > > SVN is supposed to be a "better CVS", etc.. But as I understand it, SVN assigns > a the same version number to every file in a set whenever any one of them > changes. I prefer the RCS and CVS approach of numbering each file independently, > so I can easily determine which files in a set have changed and which haven't. > This ability was critical for me when I was doing kernel/ device driver > development and comparing/ using various FreeBSD, NetBSD, and OpenBSD source > files. At the time they all used RCS/ CVS numbering, so it was easy to see what > files were the same and what were different between the platforms. I much prefer SVN to CVS after using it some in the context of a somewhat bloated repository...though I prefer it for small ones as well. I very much consider the revision scheme you mention a feature rather than a bug. It almost completely invalidates the need for static tagging among other things. SVN is considerably more complex to install and manage than CVS, but not to bad with ports and a simple mode of access (of which there are several.) Many open-source projects are switching or starting out under SVN these days, so that would be a choice factor...if I were making the choice. http://svnbook.red-bean.com/ Thanks, - Tom > > > HTH, > > David > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" > --
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070912073638.GA51618>