Date: Wed, 12 Sep 2007 10:45:01 -0300 From: Agus <agus.262@gmail.com> To: "Tom Huppi" <tomh@huppi.com> Cc: keramida@ceid.upatras.gr, dkelly@hiwaay.net, David Christensen <dpchrist@holgerdanske.com>, freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: Which versioning system is the simplest to use?? Message-ID: <fda61bb50709120645r270b762fhf7da8d7b511f471d@mail.gmail.com> In-Reply-To: <20070912073638.GA51618@huppi.com> References: <fda61bb50709111141h3dc9ae6dxc011c485eea83784@mail.gmail.com> <00c401c7f4ff$f8959960$0a00a8c0@a64x23800p> <20070912073638.GA51618@huppi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Wow...Thanks a lot guys for your very nice responses....I will investigate a litlle all the choices u gave me....but i think i will go for cvs, as i dont need anything "fancy"...just to keep it simple..... Very much appreciated.... Thanks and we 'll probably see again on another topic....haha.... C ya... Agustin 2007/9/12, Tom Huppi <tomh@huppi.com>: > > 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?fda61bb50709120645r270b762fhf7da8d7b511f471d>